Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)

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.