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
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 |