Re: RangeTblEntry jumble omissions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: RangeTblEntry jumble omissions
Дата
Msg-id ZdvkmHufaqcPYMtc@paquier.xyz
обсуждение исходный текст
Ответ на Re: RangeTblEntry jumble omissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: RangeTblEntry jumble omissions  (Peter Eisentraut <peter@eisentraut.org>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Preserve subscription OIDs during pg_upgrade
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Shared detoast Datum proposal