| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
| Subject: | Re: Making Vars outer-join aware |
| Date: | 2022-08-17 20:17:36 |
| Message-ID: | 2060462.1660767456@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> BTW, the comment just above the two calls to build_joinrel_tlist says:
> * Create a new tlist containing just the vars that need to be output from
> Here by 'vars' it means both plain Vars and PlaceHolderVars, right? If
> not we may need to adjust this comment to also include PlaceHolderVars.
I think it did intend just Vars because that's all that
build_joinrel_tlist did; but we really should have updated it when we
invented PlaceHolderVars, and even more so now that build_joinrel_tlist
adds PHVs too. I changed the wording.
> A minor comment is that seems we can get rid of phid inside
> PlaceHolderInfo, since we do not do linear list searches any more. It's
> some duplicate to the phid inside PlaceHolderVar. Currently there are
> two places referencing PlaceHolderInfo->phid, remove_rel_from_query and
> find_placeholder_info. We can use PlaceHolderVar->phid instead in both
> the two places.
Meh, I'm not excited about that. I don't think that the phid field
is only there to make the search loops faster; it's the basic
identity of the PlaceHolderInfo.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yura Sokolov | 2022-08-17 20:36:59 | plpython causes assertions with python debug build |
| Previous Message | Marcos Pegoraro | 2022-08-17 20:09:22 | Re: cataloguing NOT NULL constraints |