Re: RangeTblEntry jumble omissions

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: RangeTblEntry jumble omissions
Дата
Msg-id
ZdvkmHufaqcPYMtc@paquier.xyz
Ответ на
Список
Дерево обсуждения
RangeTblEntry jumble omissions Peter Eisentraut <peter@eisentraut.org>
Re: RangeTblEntry jumble omissions Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: RangeTblEntry jumble omissions Julien Rouhaud <rjuju123@gmail.com>
Re: RangeTblEntry jumble omissions Julien Rouhaud <rjuju123@gmail.com>
Re: RangeTblEntry jumble omissions Tom Lane <tgl@sss.pgh.pa.us>
Re: RangeTblEntry jumble omissions Michael Paquier <michael@paquier.xyz>
Re: RangeTblEntry jumble omissions Peter Eisentraut <peter@eisentraut.org>
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote:
> Julien Rouhaud  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
В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Andy Fan
Дата:
FAQ