Re: Odd Shortcut behaviour in PG14

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(at)oliver(dot)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?
>
>
>