Date: Sat, 10 Jun 2017 15:04:19 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
	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
Message-ID: <20170610180419.2gref4t7oipjcri5@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ujeevgxln6xej4pv"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5259.1497044025@sss.pgh.pa.us>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--ujeevgxln6xej4pv
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Tom Lane wrote:
> I wrote:
> > 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.
> 
> Here's an expanded version of the "bottom up" patch that adjusts some
> parser APIs to allow these additional messages to be thrown.  This changes
> all occurrences of "set-valued function called in context that cannot
> accept a set" in the core regression tests into something more specific.
> There are probably some remaining cases that this doesn't cover, but the
> existing execution-time checks will still catch those.

Interesting stuff.  Here's a small recommendation for a couple of those
new messages.


-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--ujeevgxln6xej4pv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="translatability.patch"

*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
***************
*** 1068,1074 **** transformAExprNullIf(ParseState *pstate, A_Expr *a)
  	if (result->opretset)
  		ereport(ERROR,
  				(errcode(ERRCODE_DATATYPE_MISMATCH),
! 				 errmsg("NULLIF operator must not return a set"),
  				 parser_errposition(pstate, a->location)));
  
  	/*
--- 1068,1075 ----
  	if (result->opretset)
  		ereport(ERROR,
  				(errcode(ERRCODE_DATATYPE_MISMATCH),
! 		/* translator: %s is name of a SQL construct, eg NULLIF */
! 				 errmsg("%s operator must not return a set", "NULLIF"),
  				 parser_errposition(pstate, a->location)));
  
  	/*
***************
*** 3041,3047 **** make_distinct_op(ParseState *pstate, List *opname, Node *ltree, Node *rtree,
  	if (((OpExpr *) result)->opretset)
  		ereport(ERROR,
  				(errcode(ERRCODE_DATATYPE_MISMATCH),
! 				 errmsg("IS DISTINCT FROM operator must not return a set"),
  				 parser_errposition(pstate, location)));
  
  	/*
--- 3042,3050 ----
  	if (((OpExpr *) result)->opretset)
  		ereport(ERROR,
  				(errcode(ERRCODE_DATATYPE_MISMATCH),
! 		/* translator: %s is name of a SQL construct, eg NULLIF */
! 				 errmsg("%s operator must not return a set",
! 						"IS DISTINCT FROM"),
  				 parser_errposition(pstate, location)));
  
  	/*

--ujeevgxln6xej4pv
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--ujeevgxln6xej4pv--