From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Mark Dilger <hornschnorter@gmail.com>, Regina Obe <lr@pcorp.us>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something
 change? CASE WHEN behavior oddity
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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 08 Jun 2017 20:26:19 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27102.1496979469.1@sss.pgh.pa.us>
Date: Thu, 08 Jun 2017 23:37:49 -0400
Message-ID: <27103.1496979469@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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