Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
От | Tom Lane |
---|---|
Тема | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) |
Дата | |
Msg-id | 23541.1551826799@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
|
Список | pgsql-bugs |
I wrote: > In v10 and later, not so much: BTW, I forgot to clarify that in unpatched v11 and HEAD, this test case appears to work, but that's only because apply_scanjoin_target_to_paths is forgetting to install the ProjectSetPath that should be there (and then, because the outer query now realizes that the inner one is dummy, we don't construct a plan with any SRF calls in it, and thus avoid getting the error reported at the top of this thread). With the patch discussed so far, we get the same crummy plan as in v10. I spent a little bit of time musing over whether we could avoid inserting a ProjectSetPath at all, which would be nice because then we'd not emit a useless ProjectSet plan node. But that seems like it'd require replacing the SRF call with something else --- maybe a null constant of the right type --- and that opens up a large can of worms in terms of getting setrefs.c to not choke. I'm doubtful that it's worth the work at all, and I certainly wouldn't risk back-patching it. regards, tom lane
В списке pgsql-bugs по дате отправления: