Search Postgresql Archives

Re: Odd Shortcut behaviour in PG14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux