Sorry for late answer,
On Wed, Mar 6, 2019 at 12:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In v10 and later, not so much:
Ouch, I should have followed more closely the comments and code in the
dummy part.
> 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).
I see.
> 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.
I agree that the RelOptInfo new flag / IS_DUMMY_REL change solution is
the best solution. Let's hope there won't be too many extensions
relying on the old IS_DUMMY_REL() macro. I'll work on a new version
of the patch to implement it. In the meantime I'll add an entry for
this bug in the next commitfest to make sure we don't miss it.
