On 10 August 2015 at 16:31, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com 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
2015-08-10 5:37 GMT+02:00 Noah Misch n...@leadboat.com:
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
Noah Misch n...@leadboat.com writes:
On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
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, SQL
I wrote:
Noah Misch n...@leadboat.com 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
Noah Misch n...@leadboat.com writes:
On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
I'm curious about your rationale for claiming that null predicate has
precedence exactly equal to according to the spec.
Both null predicate and comparison predicate are in the set of productions
On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
I'm curious about your rationale for claiming that null predicate has
precedence exactly equal to according to the spec.
Both null
Noah Misch n...@leadboat.com writes:
SQL has two groups of IS tests with different precedence. The boolean test
productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower than
, and the null predicate productions IS [NOT] NULL have precedence equal
to . (An implementation
On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
SQL has two groups of IS tests with different precedence. The boolean
test
productions IS [NOT] {TRUE | FALSE | UNKNOWN} have precedence just lower
than
, and the null predicate productions
On Sun, Aug 09, 2015 at 07:16:02PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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.
Noah Misch n...@leadboat.com 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
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
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 robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
I would vote for Auto meaning On in the .0 release.
I
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com 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
On Wed, Mar 11, 2015 at 8:36 PM, Kevin Grittner kgri...@ymail.com 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
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
On Wed, Mar 11, 2015 at 4:36 PM, Kevin Grittner kgri...@ymail.com 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
On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner kgri...@ymail.com 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
Greg Stark st...@mit.edu wrote:
On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner kgri...@ymail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 11, 2015 at 6:19 PM, Kevin Grittner kgri...@ymail.com 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
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kgri...@ymail.com 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
On Wed, Mar 11, 2015 at 7:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com 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
Kevin Grittner kgri...@ymail.com writes:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Do we have consensus on doing this? Should we have the warning
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
My suggestion was to treat this like the standard_conforming_string
change. That is, warn for
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
I would vote for Auto meaning On in the .0 release.
I don't think users will appreciate an auto
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 and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net
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
On 3/10/15 1:12 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com 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
Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us 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
Alex Hunsaker bada...@gmail.com writes:
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs si...@2ndquadrant.com writes:
On 20 February 2015 at 20:44, Tom Lane t...@sss.pgh.pa.us 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
Andres Freund and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net
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.
On 2/26/15 4:09 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net 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
On 2015-02-26 20:13:34 +, Simon Riggs wrote:
On 26 February 2015 at 15:56, Tom Lane t...@sss.pgh.pa.us 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
On 20 February 2015 at 20:44, Tom Lane t...@sss.pgh.pa.us 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
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
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
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
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 pete...@gmx.net 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
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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?)
Kevin Grittner kgri...@ymail.com 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
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
the precedence of = = and is neither sane nor standards compliant.
I wonder whether it would be feasible to have an option to generate
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 accepted
Peter Eisentraut pete...@gmx.net 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.
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
56 matches
Mail list logo
