Odd Shortcut behaviour in PG14 - Mailing list pgsql-general

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)

This code has worked up till now and works on the dev server. The expectation being that if ekey=0 the lateral join will be ignored. However on the new QA server this is hit and miss. It fails many times as it seems to ignore the shortcut even though ekey is 0. We can make it work by doing this:

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?

Zahir Lalani
Director of Enterprise Systems

151 Rosebery Avenue

London EC1R 4AB

t: +44 (0)7956 455 168

e: zahirlalani@oliver.agency

Thank you for your email. For a faster response please take note of the below:

1. If your query is regarding a hosting issue/new request, please direct your request to Devops.support@oliver.agency
2. If your request is regarding the data warehouse or zoho, please direct your request to mi_reporting@oliver.agency
3. If your request is regarding OMG issues/configuration, please direct your request to omgsupport@oliver.agency

For all other requests I will try and respond as soon as I can. Please note our response SLA’s

• Critical (P1) – systems down or unresponsive = within 1 hour
• High (P2) – Issues with data accuracy/access/functional = within 4 business hours
• Medium (P3) – new requests / amendments to current setups etc = within 2 business days
• Low – general requests regarding any system = best endeavour