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
Date: Sun, 28 May 2017 14:03:26 -0400
Message-ID: <21809.1495994606@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
"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
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: tgl@sss.pgh.pa.us, lr@pcorp.us
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
In-Reply-To: <21809.1495994606@sss.pgh.pa.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