From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: 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: Thu, 08 Jun 2017 23:37:49 -0400
Message-ID: <27103.1496979469@sss.pgh.pa.us> (raw)
In-Reply-To: <20170609032619.crv3skkf7tvzj63j@alap3.anarazel.de>
References: <20170603024503.yv6gxvkyx6mtc63m@alap3.anarazel.de>
<7181.1496458380@sss.pgh.pa.us>
<20170603031127.fqg7zjhfgbcbcank@alap3.anarazel.de>
<4125B63A-886A-442D-9932-34F0D4F76D41@gmail.com>
<20170604193521.ha6d5kpkdswmissm@alap3.anarazel.de>
<63850C96-9570-4969-8074-7033DA4C334F@gmail.com>
<20170604211942.aiavcbagsho5owcz@alap3.anarazel.de>
<FB5BA655-95A0-4EC5-900D-2582D3E98A74@gmail.com>
<13450.1496861842@sss.pgh.pa.us>
<25987.1496977553@sss.pgh.pa.us>
<20170609032619.crv3skkf7tvzj63j@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-08 23:05:53 -0400, Tom Lane wrote:
>> ... The first
>> attached patch does it that way, and it seems nice and clean, but I ran
>> into a complete dead end while trying to extend it to handle related cases
>> such as disallowing SRF-inside-aggregate or nested SRFs in FROM.
> But, do we really need to handle those? IOW, isn't handling
> CASE/COALESCE, which we can recognize early in parse analysis,
> sufficient to error out here? It'd be a lot nicer if we could error
> about SRF arguments to aggregates et al. during analysis rather than
> execution, but there's not a comparably huge need to improve there.
Yes, we already have guards for those cases, but they return fairly opaque
error messages to the tune of "set-valued function called in context that
cannot accept a set", because the executor hasn't enough context to do
better. I'd like the messages to be more specific, like "set-valued
function cannot appear within CASE" and so on. Anyway the point here is
to evaluate different approaches to changing the parser on the basis of
whether they *could* be extended to handle related cases. Whether we
actually do that right now is less important.
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, andres@anarazel.de, hornschnorter@gmail.com, lr@pcorp.us
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
In-Reply-To: <27103.1496979469@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