Re: proposal: ANSI SQL 2011 syntax for named parameters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters
Date: 2013-02-08 05:05:12
Message-ID: 29008.1360299912@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Dunstan 2013-02-08 05:45:32 Re: [HACKERS] JPA + enum == Exception
Previous Message Tom Lane 2013-02-08 04:55:22 Re: [HACKERS] JPA + enum == Exception