Re: Odd Shortcut behaviour in PG14 - Mailing list pgsql-general

From Ron Johnson
Subject Re: Odd Shortcut behaviour in PG14
Date
Msg-id CANzqJaCUroe03WUn1gdGK334ivyYPus338CfvMsBknudWGqFpg@mail.gmail.com
Whole thread Raw
In response to Odd Shortcut behaviour in PG14  (Zahir Lalani <ZahirLalani@oliver.agency>)
Responses Re: Odd Shortcut behaviour in PG14  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Atul Kumar
Date:
Subject: IPV6 issue
Next
From: Andreas Kretschmer
Date:
Subject: Re: IPV6 issue