From: Regina Obe <lr@pcorp.us>
To: 'Tom Lane' <tgl@sss.pgh.pa.us>
Cc: 'PostgreSQL-development' <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
Date: Fri, 26 May 2017 15:14:37 -0400
Message-ID: <000c01d2d654$518f2be0$f4ad83a0$@pcorp.us> (raw)
In-Reply-To: <29994.1495809534@sss.pgh.pa.us>
References: <000001d2d5de$d8d66170$8a832450$@pcorp.us>
<29994.1495809534@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
> "Regina Obe" <lr@pcorp.us> writes:
>> I figured out the culprit was the change in CASE WHEN behavior with
>> set returning functions Had a criteria something of the form:
>> CASE WHEN some_condition_dependent_on_sometable_that_resolves_to_false
>> THEN (regexp_matches(...))[1] ELSE ... END FROM sometable;
> You might want to consider changing such usages to use regexp_match()
instead of regexp_matches().
> regards, tom lane
Thanks. I ended up swapping out with substring which was a bit shorter than
regexp_match()[].
But I've got similar problems with PostGIS topology logic and the easiest
change to make was take advantage
of the fact that you guys are treating CASE constant ... THEN SRF ...
Differently
Than
CASE not_constant_based_on_table_value THEN SRF ..
So I switched those to constant checks. This feels a little dirty and
fragile to me though.
Is this behavior going to stay or change?
It seems inconsistent from a user perspective that
CASE constant .... == short-circuit skipping over SRFs that may otherwise
fail
While
CASE not_constant_table_dependent doesn't short-circuit.
I can understand the motive behind it, it just feels a little inconsistent
from an end-user POV.
Thanks,
Regina
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: lr@pcorp.us, tgl@sss.pgh.pa.us
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
In-Reply-To: <000c01d2d654$518f2be0$f4ad83a0$@pcorp.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox