|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, thibaut(dot)madelaine(at)dalibo(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> I've already got a mostly-working patch. It's causing one plan change
> in select_parallel that I've not quite figured out the reason for, or
> I should say that it's not obvious why the existing code appears to
And here 'tis. I spent some time improving the existing comments, because
it's not very clear what some of this is doing or why it has to be done
I renamed IS_DUMMY_PATH to IS_DUMMY_APPEND, because almost anything that
might've been using it is probably wrong now; there's only one valid
use-case left in the core code, other than is_dummy_rel itself.
I noticed that there's no reason any more for set_dummy_rel_pathlist to
be global: it's not called from outside allpaths.c, and anything that
might want to call it would be better off using mark_dummy_rel anyway.
Also, there's no reason for is_dummy_plan to exist at all: that's a
leftover from days when recursing into a subquery produced a completed
Plan rather than some Paths. So this patch includes those cleanups,
but I don't propose back-patching those changes.
I have to leave for today, but unless somebody complains, I'm intending
to push this tomorrow.
regards, tom lane
|Next Message||Julien Rouhaud||2019-03-06 20:23:33||Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)|
|Previous Message||Tom Lane||2019-03-06 18:23:49||Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)|