> "Regina Obe" <l...@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
