Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simplifies a bit a code around printing and parsing of tsquery.
|, &, <->, ! of course
--
Teodor Sigaev E-mail: teo...@sigaev.ru
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane wrote:
It appears that the new <-> operator has been made to have exactly the
same grammatical precedence as the existing & (AND) operator. Thus,
for example, 'a & b <-> c'::tsquery means something different from
'b <-> c & a'::tsquery:
I find this surpr
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane wrote:
> It appears that the new <-> operator has been made to have exactly the
> same grammatical precedence as the existing & (AND) operator. Thus,
> for example, 'a & b <-> c'::tsquery means something different from
> 'b <-> c & a'::tsquery:
>
> regress
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane wrote:
> It appears that the new <-> operator has been made to have exactly the
> same grammatical precedence as the existing & (AND) operator. Thus,
> for example, 'a & b <-> c'::tsquery means something different from
> 'b <-> c & a'::tsquery:
>
> regress
It appears that the new <-> operator has been made to have exactly the
same grammatical precedence as the existing & (AND) operator. Thus,
for example, 'a & b <-> c'::tsquery means something different from
'b <-> c & a'::tsquery:
regression=# select 'a & b <-> c'::tsquery;
tsquery
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
Bruce Momjian writes:
> On Wed, Apr 8, 2015 at 01:14:38PM -0400, Tom Lane wrote:
>> Greg Stark writes:
>>> On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote:
Also, it strikes me that we could significantly reduce, maybe even fully
eliminate, the funny behaviors around the existing base_
On Wed, Apr 8, 2015 at 01:14:38PM -0400, Tom Lane wrote:
> Greg Stark writes:
> > On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote:
> >> Also, it strikes me that we could significantly reduce, maybe even fully
> >> eliminate, the funny behaviors around the existing base_yylex()
> >> substitutions
Greg Stark writes:
> On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote:
>> Also, it strikes me that we could significantly reduce, maybe even fully
>> eliminate, the funny behaviors around the existing base_yylex()
>> substitutions if we made them use the same idea, ie replace the leading
>> token
On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote:
> Also, it strikes me that we could significantly reduce, maybe even fully
> eliminate, the funny behaviors around the existing base_yylex()
> substitutions if we made them use the same idea, ie replace the leading
> token with something special but
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
Peter Eisentraut writes:
> On 2/23/15 3:08 PM, Tom Lane wrote:
>> I thought of another possibility:
>>
>> 3. Leave everything as-is but mark the NOT-operator productions as having
>> the precedence of NOT rather than of LIKE etc. This would change the
>> behavior only for the NOT-LIKE-followed-b
On 2/23/15 3:08 PM, Tom Lane wrote:
> I thought of another possibility:
>
> 3. Leave everything as-is but mark the NOT-operator productions as having
> the precedence of NOT rather than of LIKE etc. This would change the
> behavior only for the NOT-LIKE-followed-by-< example, and would make the
>
I wrote:
> I'm not seeing any terribly pleasing ways to fix this. Aside from
> the option of doing nothing, it seems like these are the choices:
> 1. We could hack base_yylex() to reduce NOT LIKE to a single token
> which could be given the same precedence as LIKE. Ditto for the other
> four cas
I wrote:
> I'm not seeing any terribly pleasing ways to fix this. Aside from
> the option of doing nothing, it seems like these are the choices:
> 1. We could hack base_yylex() to reduce NOT LIKE to a single token
> which could be given the same precedence as LIKE. Ditto for the other
> four cas
While fooling around with testing operator precedence warnings,
I discovered that there's some existing precedence behavior that's
not at all what I expected. Consider these examples (all done in
9.4; this is longstanding behavior):
regression=# SELECT 1 < '(3,4)'::point LIKE 42.0;
ERROR: operat
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
My Salesforce colleagues have been bugging me about this topic, and
since I see in a nearby thread that we may be about to break backwards
compatibility on "=>", maybe it's time to do something about this too.
To wit, that the precedence of <= >= and <> is neither sane nor standards
compliant.
Up
Thanks Tom, for the explanation.
Gokul.
On Sun, Feb 7, 2010 at 10:14 PM, Tom Lane wrote:
> Gokulakannan Somasundaram writes:
> >Is there any reason why we have given lesser precedence for postfix
> > operator compared to multiplication/division? Usually postfix operators
> have
> > more pr
Gokulakannan Somasundaram writes:
>Is there any reason why we have given lesser precedence for postfix
> operator compared to multiplication/division? Usually postfix operators have
> more precedence than the binary operations. Is this some kind of work around
> to provide user-defined operato
Hi,
Is there any reason why we have given lesser precedence for postfix
operator compared to multiplication/division? Usually postfix operators have
more precedence than the binary operations. Is this some kind of work around
to provide user-defined operators? Can someone help me understand this
Now that I look, it doesn't look like these operators are documented
at all in the SGML docs, so it sure seems that removing them should be
pretty painless.
I'd agree with that
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmas
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Jun 5, 2005, at 12:55 AM, Tom Lane wrote:
>> Now that I look, it doesn't look like these operators are documented
>> at all in the SGML docs, so it sure seems that removing them should be
>> pretty painless.
> I wonder what else is lurking around
On Jun 5, 2005, at 12:55 AM, Tom Lane wrote:
Now that I look, it doesn't look like these operators are documented
at all in the SGML docs, so it sure seems that removing them should be
pretty painless.
I wonder what else is lurking around undocumented and unused? Might
be some other nuggets
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I don't even grasp what unary modulo actually means???
At some point in the dim mists of prehistory, somebody thought it would
be cute to define prefix % as trunc() and postfix % as round(). I'm not
aware of any precedent for that; it was prob
round() and trunc() also have the virtue that they already have versions
for type numeric. If we keep the operators then we'll be right back
with the complaint that was lodged the other day about exponentiation,
namely unexpected precision loss for numeric inputs:
regression=# select 12345678901
Tom Lane wrote:
> We could possibly fix this by fooling with the precedence of the
> productions for postfix '%', but I'm worried that that would have
> unintended side-effects. What I'd like to propose instead is that
> we remove prefix and postfix '%' entirely --- and also '^', which
> is the on
I wrote:
> Bruce Momjian writes:
>> Does anyone understand why the precedence of % is strange:
>> test=> select -25 % -10;
> It's treating it as ((-25) %) - (10), which is probably not so
> surprising given the relative precedence of % and - ... though
> I have to admit I'm not totally clear why
Bruce Momjian writes:
> Does anyone understand why the precedence of % is strange:
> test=> select -25 % -10;
It's treating it as ((-25) %) - (10), which is probably not so
surprising given the relative precedence of % and - ... though
I have to admit I'm not totally clear why it's not (-(2
Does anyone understand why the precedence of % is strange:
test=> select -25 % -10;
?column?
--
-35
(1 row)
test=> select -25 % (-10);
?column?
--
-5
(1 row)
Is it treat
91 matches
Mail list logo
