Re: RangeTblEntry jumble omissions
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-02-26T01:08:40Z
Lists: pgsql-hackers
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote: > Julien Rouhaud <rjuju123@gmail.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. +1. >>> - 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. Sounds like a fair argument to me. Btw, I think that you should add a few queries to the tests of pg_stat_statements to track the change of behavior when you have aliases, as an effect of the fields added in the jumbling. -- Michael
Commits
-
Add missing RangeTblEntry field to jumble
- 8b29a119fdaa 17.0 landed