On 10 August 2015 at 16:31, Tom Lane wrote:
> Pavel Stehule writes:
> >> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
> >>> So yeah, I do think that getting a syntax error if you don't use
> >>> parentheses is the preferable behavior here.
>
> > If we raise a syntax error, then ther
Pavel Stehule writes:
>> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
>>> So yeah, I do think that getting a syntax error if you don't use
>>> parentheses is the preferable behavior here.
> If we raise a syntax error, then there should be very informative message,
Yeah, it would sur
2015-08-10 5:37 GMT+02:00 Noah Misch :
> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > In SQL:2008 and SQL:2011 at least, "=", "<" and "BETWEEN" are all in
> the same
> > > boat. They have no precedence relationships to each other; SQL
> sidesteps the
> >
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > In SQL:2008 and SQL:2011 at least, "=", "<" and "BETWEEN" are all in the
> > same
> > boat. They have no precedence relationships to each other; SQL sidesteps
> > the
> > question by requiring parentheses. They
Noah Misch writes:
> On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>>> It does risk that. Same deal with making "=" have the same precedence as
>>> "<"
>>> instead of keeping it slightly lower.
>> Agreed, but in that case I think our hand is forced by the SQL
On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
> >> So for our
> >> purposes, it's better to keep BETWEEN and friends as binding slightly
> >> tighter than '<' than to make them the same precedence. Same
Noah Misch writes:
> On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
>> So for our
>> purposes, it's better to keep BETWEEN and friends as binding slightly
>> tighter than '<' than to make them the same precedence. Same precedence
>> risks breaking things that weren't broken before.
>
On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
> >> I'm curious about your rationale for claiming that has
> >> precedence exactly equal to "<" according to the spec.
>
> > Both and are in the set of
Noah Misch writes:
> On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
>> I'm curious about your rationale for claiming that has
>> precedence exactly equal to "<" according to the spec.
> Both and are in the set of productions
> that take arguments and appear only in .
> Passing a pr
On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > SQL has two groups of IS tests with different precedence. The > test>
> > productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower
> > than
> > "<", and the productions IS [NOT] NULL have precede
I wrote:
> Noah Misch writes:
>> Why in particular the following three precedence groups instead of
>> combining them as in SQL or subdividing further as in PostgreSQL 9.4?
> +%nonassoc'<' '>' '=' LESS_EQUALS GREATER_EQUALS NOT_EQUALS
> +%nonassocBETWEEN IN_P LIKE ILIKE SIMILAR NOT_LA
> %
Noah Misch writes:
> SQL has two groups of IS tests with different precedence. The
> productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower than
> "<", and the productions IS [NOT] NULL have precedence equal
> to "<". (An implementation giving them the same precedence can con
On Thu, Feb 19, 2015 at 10:48:34AM -0500, Tom Lane wrote:
> To wit, that the precedence of <= >= and <> is neither sane nor standards
> compliant.
> I claim that this behavior is contrary to spec as well as being
> unintuitive. Following the grammar productions in SQL99:
Between 1999 and 2006, S
On Tue, Mar 10, 2015 at 04:10:01PM -0400, Peter Eisentraut wrote:
> On 3/10/15 1:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
> >> wrote:
> >>> I would vote for Auto meaning On in the .0 release.
> >
> >> I don't think users will appreci
On Wed, Mar 11, 2015 at 8:36 PM, Kevin Grittner wrote:
> Right; and they may have millions of lines of code which have been
> carefully tested and in production for years, and which may
> suddenly start to generate incorrect results on queries *or mangle
> existing data* with the fix unless they
On 3/10/15 4:34 PM, Tom Lane wrote:
> There's one more reason, too: the code I have is designed to give correct
> warnings within the context of a parser that parses according to the
> spec-compliant rules. It's possible that a similar approach could be used
> to generate correct warnings within a
Robert Haas writes:
> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
> wrote:
>> I would vote for Auto meaning On in the .0 release.
> I don't think users will appreciate an auto value whose meaning might
> change at some point, and I doubt we've have much luck identifying the
> correct poi
Robert Haas writes:
> Just out of curiosity, does this change create a dump-and-reload
> hazard? Like if I pg_upgrade my cluster, will the output of pg_dump
> potentially be sufficiently under-parenthesized that reload will
> create a non-equivalent database?
No. Had there been any such hazard,
On Wed, Mar 11, 2015 at 7:49 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> If there are no false positives, turning it on is zero impact
>> (except for any performance impact involved in detecting the
>> condition) for those who have no problems. That will probably be
>> the vast majority of u
On Wed, Mar 11, 2015 at 6:19 PM, Kevin Grittner wrote:
> Either way it is like leaving the barn door open so that horses are
> capable of running out. We have an alarm that lets you know when
> something is going through the barn door; the question is whether
> to default that alarm on or off.
W
Kevin Grittner writes:
> If there are no false positives, turning it on is zero impact
> (except for any performance impact involved in detecting the
> condition) for those who have no problems. That will probably be
> the vast majority of users. The question is, do we want to quietly
> do somet
Kevin Grittner writes:
> Robert Haas wrote:
>> Can you, or can anyone, show a plausible example of something
>> that would work under the old rules and work under the new rules
>> but with a different meaning? I have to admit that I'm having
>> some difficulty imagining exactly when that happens
Robert Haas wrote:
> Can you, or can anyone, show a plausible example of something
> that would work under the old rules and work under the new rules
> but with a different meaning? I have to admit that I'm having
> some difficulty imagining exactly when that happens. Tom's
> examples upthread
On Wed, Mar 11, 2015 at 4:36 PM, Kevin Grittner wrote:
> If we ship with this off the results are entirely predictable. It
> will be somewhat surprising not to see any negative headlines about
> it.
Can you, or can anyone, show a plausible example of something that
would work under the old rules
Greg Stark wrote:
> On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner wrote:
>> If there are no false positives, turning it on is zero impact
>> (except for any performance impact involved in detecting the
>> condition) for those who have no problems.
> Think of this as a bug fix.
I do. :-)
>
On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner wrote:
> If there are no false positives, turning it on is zero impact
> (except for any performance impact involved in detecting the
> condition) for those who have no problems.
>
Think of this as a bug fix. Hopefully nobody was using the syntax b
Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
Another possibility is to leave it on through beta testing
with the intent to turn it off before 9.5 final; that would
give us more data about whether there are real issues than
I wrote:
> Robert Haas writes:
>> On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
>>> Another possibility is to leave it on through beta testing with the intent
>>> to turn it off before 9.5 final; that would give us more data about
>>> whether there are real issues than we're likely to get othe
Peter Eisentraut writes:
> Well, I point again to standards_conforming_strings: Leave the warning
> off for one release (or more), then default to on for one (or more),
> then change the behavior.
> We can change the timeline, but I don't think the approach was unsound.
I'm not excited about that
On 3/10/15 1:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
>> wrote:
>>> I would vote for Auto meaning On in the .0 release.
>
>> I don't think users will appreciate an auto value whose meaning might
>> change at some point, and I doubt we've
Alex Hunsaker writes:
> On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote:
>> This thread seems to have died off without any clear resolution. I'd
>> hoped somebody would try the patch on some nontrivial application to
>> see if it broke anything or caused any warnings, but it doesn't seem
>> lik
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote:
> I wrote:
>
> This thread seems to have died off without any clear resolution. I'd
> hoped somebody would try the patch on some nontrivial application to
> see if it broke anything or caused any warnings, but it doesn't seem
> like that is happe
Robert Haas writes:
> On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
>> Another possibility is to leave it on through beta testing with the intent
>> to turn it off before 9.5 final; that would give us more data about
>> whether there are real issues than we're likely to get otherwise.
> To my
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
>> wrote:
>>> I would vote for Auto meaning On in the .0 release.
>
>> I don't think users will appreciate an auto value whose meaning might
>> change at some point, and
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
wrote:
> On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas wrote:
>> On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote:
>> > Do we have consensus on doing this? Should we have the warning on
>> > by default, or off?
>>
>> I vote for defaulting the w
On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas wrote:
> On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote:
> > Do we have consensus on doing this? Should we have the warning on
> > by default, or off?
>
> I vote for defaulting the warning to off. If that proves to be too
> problematic, I'd take
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut
>>> wrote:
My suggestion was to treat this like the standard_conforming_string
change. That is, warn for many years before changing.
>
>>>
Tom Lane wrote:
> Do we have consensus on doing this? Should we have the warning on
> by default, or off?
This is the tough decision, isn't it. I had thought it would default to
off and people would only turn it on in their testing procedure prior to
the actual upgrade of the production systems
I wrote:
> Andres Freund writes:
>> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut
>> wrote:
>>> My suggestion was to treat this like the standard_conforming_string
>>> change. That is, warn for many years before changing.
>> I don't think scs is a good example to follow.
> Yeah. For
On 2015-02-26 20:13:34 +, Simon Riggs wrote:
> On 26 February 2015 at 15:56, Tom Lane wrote:
>
> >> I think the way to do this is to have a pluggable parser, so users can
> >> choose 1) old parser, 2) new, better parser, 3) any other parser they
> >> fancy that they maintain to ensure applica
On 2/26/15 4:09 PM, Tom Lane wrote:
Andres Freund writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut wrote:
My suggestion was to treat this like the standard_conforming_string
change. That is, warn for many years before changing.
I don't think scs is a good example to follow.
Andres Freund writes:
> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut
> wrote:
>> My suggestion was to treat this like the standard_conforming_string
>> change. That is, warn for many years before changing.
> I don't think scs is a good example to follow.
Yeah. For one thing, there
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut wrote:
>On 2/25/15 5:15 PM, Simon Riggs wrote:
>> Having a warn_if_screwed parameter that we disable by default won't
>> help much because if you are affected you can't change that
>situation.
>> There are too many applications to test all of
On 2/25/15 5:15 PM, Simon Riggs wrote:
> Having a warn_if_screwed parameter that we disable by default won't
> help much because if you are affected you can't change that situation.
> There are too many applications to test all of them and not all
> applications can be edited, even if they were tes
Simon Riggs writes:
> On 26 February 2015 at 15:56, Tom Lane wrote:
>> I don't find that particularly attractive either. It seems quite unlikely
>> to me that anyone would actually use such a hook; replacing the whole
>> parser would be essentially unmaintainable. Nobody uses the hooks you
>> m
On 26 February 2015 at 15:56, Tom Lane wrote:
>> I think the way to do this is to have a pluggable parser, so users can
>> choose 1) old parser, 2) new, better parser, 3) any other parser they
>> fancy that they maintain to ensure application compatibility. We've
>> got a pluggable executor and o
Andrew Dunstan writes:
> On 02/26/2015 10:56 AM, Tom Lane wrote:
>> I find this argument to be unhelpful, because it could be made in exactly
>> the same words against any non-backwards-compatible change whatsoever.
>> Nonetheless, we do make non-backwards-compatible changes all the time.
> That'
On 02/26/2015 10:56 AM, Tom Lane wrote:
Simon Riggs writes:
On 20 February 2015 at 20:44, Tom Lane wrote:
Well, assuming that we're satisfied with just having a way to warn
when the behavior changed (and not, in particular, a switch that can
select old or new behavior)
I'm in favour of your
Simon Riggs writes:
> On 20 February 2015 at 20:44, Tom Lane wrote:
>> Well, assuming that we're satisfied with just having a way to warn
>> when the behavior changed (and not, in particular, a switch that can
>> select old or new behavior)
> I'm in favour of your proposed improvements, but I'm
On 20 February 2015 at 20:44, Tom Lane wrote:
> Well, assuming that we're satisfied with just having a way to warn
> when the behavior changed (and not, in particular, a switch that can
> select old or new behavior)
I'm in favour of your proposed improvements, but I'm having a problem
thinking a
Here's a completed patch for this. This includes fixing the NOT LIKE
problem as discussed in the other thread.
I've done more-or-less-exhaustive testing on this to verify that it
produces warnings whenever necessary. It generates a few false-positive
warnings in corner cases that seem too compli
Attached is an improved patch that includes optional warnings for
constructs that changed parsing. It's not quite 100% but I think it's
about 90% correct; the difference in size between this and the previous
patch should be a pretty fair indication of what it's going to cost us
to have a warning c
I wrote:
> Attached is a draft patch to bring the precedence of comparison operators
> and IS tests into line with the SQL standard. I have not yet looked into
> producing warnings for changes in parsing decisions ...
I've made some progress on getting parse_expr.c to produce warnings by
after-th
Attached is a draft patch to bring the precedence of comparison operators
and IS tests into line with the SQL standard. I have not yet looked into
producing warnings for changes in parsing decisions; but I was gratified
to discover that this patch results in none, nada, zero changes in any
of our
Peter Eisentraut writes:
> We could check if there is a >= or <= as a child of another general
> operator. That is already quite unlikely to begin with (except for the
> obvious common case I am forgetting right now). We could even do this
> in an external module with a hook. Or to be more prec
On 2/20/15 2:41 PM, Tom Lane wrote:
> I don't believe there is any practical way for us to generate useful
> warnings here; as I said to Kevin, I don't think that Bison exposes
> sufficient information to detect when a parsing decision was made
> differently than before because of precedence.
We c
Peter Eisentraut writes:
> I think we should try to do it, but we need a way for users to see what
> is going on. If we just put into the release notes, "the precedences of
>> = and <= have been changed, but we don't expect this to cause many
> problems", there might be wide-spread panic.
> One
On 2/19/15 10:48 AM, Tom Lane wrote:
> I've not really experimented with this at all; it would be useful for
> example to see how many regression tests break as a gauge for how
> troublesome such changes would be. I thought I'd ask whether there's
> any chance at all of such a change getting accep
Tom Lane wrote:
> One of the reasons I want to make these operators %nonassoc is
> so you get an error on cases like these --- if you actually meant
> this, you'll be forced to parenthesize one way or the other.
I could live with that versus a configurable warning. It's simpler
and makes it le
Kevin Grittner wrote:
> Tom Lane wrote:
>> Kevin Grittner writes:
>>> Tom Lane wrote:
the precedence of <= >= and <> is neither sane nor standards compliant.
>>>
>>> I wonder whether it would be feasible to have an option to generate
>>> warnings (or maybe just LOG level messages?) for que
Kevin Grittner writes:
> I have a memory of running into this in real-world production code
> and that it involved booleans. I'll see whether I posted something
> to the community lists about it, but it didn't take long to produce
> an (admittedly artificial) case where incorrect results are
> si
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> the precedence of <= >= and <> is neither sane nor standards compliant.
>> I wonder whether it would be feasible to have an option to generate
>> warnings (or maybe just LOG level messages?) for queries where the
>> results could d
Kevin Grittner writes:
> Tom Lane wrote:
>> the precedence of <= >= and <> is neither sane nor standards compliant.
> I wonder whether it would be feasible to have an option to generate
> warnings (or maybe just LOG level messages?) for queries where the
> results could differ.
My guess (admitt
Tom Lane wrote:
> the precedence of <= >= and <> is neither sane nor standards compliant.
+1
That was a bit of a pain when I migrated a lot of code from Sybase
ASE to PostgreSQL; I think we should conform to the standard on
this, even if it breaks backward compatibility. (Of course, the
releas
64 matches
Mail list logo
