From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Regina Obe" <lr@pcorp.us>
cc: "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something
 change? CASE WHEN behavior oddity
In-reply-to: <000c01d2d654$518f2be0$f4ad83a0$@pcorp.us>
References: <000001d2d5de$d8d66170$8a832450$@pcorp.us>
 <29994.1495809534@sss.pgh.pa.us> <000c01d2d654$518f2be0$f4ad83a0$@pcorp.us>
Comments: In-reply-to "Regina Obe" <lr@pcorp.us>
	message dated "Fri, 26 May 2017 15:14:37 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21808.1495994606.1@sss.pgh.pa.us>
Date: Sun, 28 May 2017 14:03:26 -0400
Message-ID: <21809.1495994606@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

"Regina Obe" <lr@pcorp.us> writes:
> 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.

After thinking about this for awhile, I agree that what we've got now
isn't too satisfactory.  We can make an analogy between SRFs and
aggregate functions: both of them look like simple function calls
syntactically, but they have global effects on the semantics of the
query, particularly on how many rows are returned.

In the case of aggregates, there is long-standing precedent that we
can optimize away individual aggregate calls but the query semantics
do not change, ie you get one output row (or one per GROUP BY group)
even if every last aggregate call disappears due to CASE simplification.
The same was true for deletion of SRFs by CASE-simplification before
v10, but now we've broken that, which seems like a clear bug.

I think it would be possible to teach eval_const_expressions that
it must not discard CASE/COALESCE subexpressions that contain SRFs,
which would preserve the rule that expression simplification doesn't
change the query semantics.

Another possibility is to say that we've broken this situation
irretrievably and we should start throwing errors for SRFs in
places where they'd be conditionally evaluated.  That's not real
nice perhaps, but it's better than the way things are right now.

Thoughts?

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers