| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RangeTblEntry jumble omissions |
| Date: | 2024-02-23 23:52:54 |
| Message-ID: | 963596.1708732374@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
>> - funcordinality
>> This was probably just forgotten. It should be included because the WITH
>> ORDINALITY clause changes the query result.
> Agreed.
Seems OK.
>> - lateral
>> Also probably forgotten. A query specifying LATERAL is clearly different
>> from one without it.
> Agreed.
Nah ... I think that LATERAL should be ignored on essentially the
same grounds on which you argue for ignoring aliases. If it
affects the query's semantics, it's because there is a lateral
reference in the subject subquery or function, and that reference
already contributes to the query hash. If there is no such
reference, then LATERAL is a noise word. It doesn't help any that
LATERAL is actually optional for functions, making it certainly a
noise word there.
IIRC, the parser+planner cooperatively fix things so that the final
state of an RTE's lateral field reflects reality. But if we are
hashing before that's happened, it's not worth all that much.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Zhang | 2024-02-24 00:10:47 | Re: Proposal for implementing OCSP Stapling in PostgreSQL |
| Previous Message | Tristen Raab | 2024-02-23 23:50:17 | Re: Documentation: warn about two_phase when altering a subscription |