Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3g9I-0001vw-6y for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Feb 2013 05:05:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1U3g9H-0005kW-73 for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Feb 2013 05:05:19 +0000 Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3g9G-0005kR-Fc for pgsql-hackers@postgresql.org; Fri, 08 Feb 2013 05:05:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3g9E-0007wg-AN for pgsql-hackers@postgresql.org; Fri, 08 Feb 2013 05:05:18 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r1855CAJ029009; Fri, 8 Feb 2013 00:05:12 -0500 (EST) From: Tom Lane To: Robert Haas cc: Simon Riggs , PostgreSQL Hackers Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters In-reply-to: References: Comments: In-reply-to Robert Haas message dated "Thu, 07 Feb 2013 06:49:32 -0500" Date: Fri, 08 Feb 2013 00:05:12 -0500 Message-ID: <29008.1360299912@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs wrote: >> IMO the way to resolve that conflict is with a behaviour parameter to >> allow people to choose, rather than be forced to wait a year because >> some people still run an old version of an add-on package. A good way >> to do that would be to have a sql_standard = postgres | 2011 etc so we >> can tick the box in having a sql standard flagger as well. > The undesirability of syntax-altering GUCs has been discussed here on > many occasions. Note that a GUC to change the behavior of the lexer or grammar is particularly undesirable, for reasons noted at the top of gram.y as well as others having to do with the behavior of plancache.c. (Hint: it caches grammar output, not raw source text.) We've put up with that for standard_conforming_strings because we pretty much had to, but that doesn't mean that introducing more such GUCs would be wise. But regardless of those particular implementation artifacts, I think most of us have come to the conclusion that GUCs that alter query semantics are far more dangerous and unpleasant-to-use than they might look. 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