Re: Odd Shortcut behaviour in PG14

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: Odd Shortcut behaviour in PG14
Дата
Msg-id CANzqJaCUroe03WUn1gdGK334ivyYPus338CfvMsBknudWGqFpg@mail.gmail.com
обсуждение исходный текст
Ответ на Odd Shortcut behaviour in PG14  (Zahir Lalani <ZahirLalani@oliver.agency>)
Ответы Re: Odd Shortcut behaviour in PG14
Список pgsql-general
Out of curiosity, what is the point of adding the "true" predicate no matter the position?  Maybe I've created an incorrect truth table, but "true AND" (and "AND true") don't make any logical difference when added to (ekey > 0).


On Thu, Nov 23, 2023 at 11:56 AM Zahir Lalani <ZahirLalani@oliver.agency> wrote:

Hello all

 

Got a really weird problem with shortcut processing on one server.

 

We have just upgraded to PG14 from PG11. The following code works as expected on our primary Dev server, and we recently upgraded our QA server to the same level. However in this case the shortcut processing seems broken.

 

Here is the code in question:

 

LEFT JOIN lateral (

    SELECT

        CASE WHEN (ekey > 0) THEN convert_from(crypto_secretbox_open, 'utf8')::JSON ELSE NULL END AS edata

        FROM crypto_secretbox_open(

                sc.data,

                sc.nonce,

                boxkey)

) enc ON true and (ekey > 0)

 

[snip] 

LEFT JOIN lateral (

    SELECT

        CASE WHEN (ekey > 0) THEN convert_from(crypto_secretbox_open, 'utf8')::JSON ELSE NULL END AS edata

        FROM crypto_secretbox_open(

                sc.data,

                sc.nonce,

                boxkey)

) enc ON (ekey > 0) and true

 

This should theoretically be no different – but it solves the issue 100%. Any guidance on why this would be the case?

 

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

Предыдущее
От: Atul Kumar
Дата:
Сообщение: IPV6 issue
Следующее
От: Andreas Kretschmer
Дата:
Сообщение: Re: IPV6 issue