> "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
