BUG #13829: Exponentiation operator is left-associative
The following bug has been logged on the website:
Bug reference: 13829
Logged by: Henrik Pauli
Email address: henrik.pauli@uhusystems.com
PostgreSQL version: 9.3.9
Operating system: Linux (Fedora)
Description:
As a result of a discussion on IRC, I'm writing a bug report here. Maybe I
should have sent it to -hackers, but I do not currently have access to that
mailing list.
The convention with exponentation is the following (according to Wikipedia):
"Without parentheses to modify the order of calculation, by convention the
order is top-down, not bottom-up" -- in programming terms, it means that
exponentation is by default right-associative.
bc, Perl, Python, PHP agree that:
3^3^3
7625597484987
3^(3^3)
7625597484987
(3^3)^3
19683
However, PostgreSQL -- as indeed mentioned in the docs -- considers the
paren-less version more like the one where the left side is parenthesised:
=> select 3^3^3 as no_paren, (3^3)^3 as left_paren, 3^(3^3) as right_paren;
no_paren | left_paren | right_paren
----------+------------+---------------
19683 | 19683 | 7625597484987
(1 row)
Which goes against the mathematics, and most programming languages'
convention.
The only place where it is possible to notice this, as far as I could see,
is the precedence table on
http://www.postgresql.org/docs/9.5/static/sql-syntax-lexical.html#SQL-PRECEDENCE
but it does not highlight neither that this unorthodoxy is due to compliance
with the SQL standard (as is common on many other documentation pages) nor
does it make note of it any other highly visible way to decrease the chance
of oversight in the user.
Clearly, changing the behaviour can cause breakage in existing programs, but
that is not unprecedented as 9.5 has recently changed operator precedence.
Chances are though that those programs were already in the wrong, and those
that weren't have already been using parentheses to fix the unexpected
behaviour. It is also likely that this operation is very rarely used (since
when used it results in incredibly large numbers very easily), as such both
the wrong behaviour, and the breakage introduced by the fixes have low
impact.
Please consider fixing the associativity so it aligns with the convention,
or at least raise a warning in the documentation about possible pitfalls.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
henrik.pauli@uhusystems.com writes:
The convention with exponentation is the following (according to Wikipedia):
"Without parentheses to modify the order of calculation, by convention the
order is top-down, not bottom-up" -- in programming terms, it means that
exponentation is by default right-associative.
...
However, PostgreSQL -- as indeed mentioned in the docs -- considers the
paren-less version more like the one where the left side is parenthesised:
Yeah. I can't see us changing this. Aside from backwards-compatibility
considerations, "^" is not so thoroughly identified with exponentiation
that no-one would ever make a custom operator named "^" that did something
else. Since operator precedence and associativity are determined solely
by the operator name, right-to-left associativity would have to apply to
such custom operators too, which would be mighty surprising if their
semantics were something else.
However, pointing the issue out somewhere near Table 9-2. Mathematical
Operators seems reasonable. The minimum change would just be to call it
out in the table entry itself:
Operator Description Example Result
...
^ exponentiation (associates left to right) 2.0 ^ 3.0 8
Do you think that's sufficient?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 22/12/15 17:00, Tom Lane wrote:
henrik.pauli@uhusystems.com writes:
The convention with exponentation is the following (according to Wikipedia):
"Without parentheses to modify the order of calculation, by convention the
order is top-down, not bottom-up" -- in programming terms, it means that
exponentation is by default right-associative.
...
However, PostgreSQL -- as indeed mentioned in the docs -- considers the
paren-less version more like the one where the left side is parenthesised:Yeah. I can't see us changing this. Aside from backwards-compatibility
considerations, "^" is not so thoroughly identified with exponentiation
that no-one would ever make a custom operator named "^" that did something
else. Since operator precedence and associativity are determined solely
by the operator name, right-to-left associativity would have to apply to
such custom operators too, which would be mighty surprising if their
semantics were something else.
The custom operator thing is one of those situations I didn't think of
and that's a reasonable problem there. That said, I guess the (few)
users with things like a^b^c in their code also find it "mighty
surprising" that it isn't a^(b^c). So one side is left scratching their
heads either way.
However, pointing the issue out somewhere near Table 9-2. Mathematical
Operators seems reasonable. The minimum change would just be to call it
out in the table entry itself:Operator Description Example Result
...
^ exponentiation (associates left to right) 2.0 ^ 3.0 8Do you think that's sufficient?
regards, tom lane
Might well be enough, not sure. Some parts of the documentation do come
with little "Note" boxes in the text (can't quite remember an exact
example, but I seem to remember there being such), which increase
visibility to such discrepancy more effectively. Might be worth a
sentence or two. I guess if there hasn't been a report before (no
idea), people just don't do this in Postgres and so haven't been bitten
by it at all.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Dec 22, 2015 at 9:55 AM, Henrik Pauli <henrik.pauli@uhusystems.com>
wrote:
On 22/12/15 17:00, Tom Lane wrote:
henrik.pauli@uhusystems.com writes:
The convention with exponentation is the following (according to
Wikipedia):
"Without parentheses to modify the order of calculation, by convention
the
order is top-down, not bottom-up" -- in programming terms, it means that
exponentation is by default right-associative.
...
However, PostgreSQL -- as indeed mentioned in the docs -- considers the
paren-less version more like the one where the left side is
parenthesised:Yeah. I can't see us changing this. Aside from backwards-compatibility
considerations, "^" is not so thoroughly identified with exponentiation
that no-one would ever make a custom operator named "^" that did something
else. Since operator precedence and associativity are determined solely
by the operator name, right-to-left associativity would have to apply to
such custom operators too, which would be mighty surprising if their
semantics were something else.The custom operator thing is one of those situations I didn't think of and
that's a reasonable problem there. That said, I guess the (few) users with
things like a^b^c in their code also find it "mighty surprising" that it
isn't a^(b^c). So one side is left scratching their heads either way.However, pointing the issue out somewhere near Table 9-2. Mathematical
Operators seems reasonable. The minimum change would just be to call it
out in the table entry itself:Operator Description Example
Result
...
^ exponentiation (associates left to right) 2.0 ^ 3.0 8Do you think that's sufficient?
regards, tom lane
Might well be enough, not sure. Some parts of the documentation do come
with little "Note" boxes in the text (can't quite remember an exact
example, but I seem to remember there being such), which increase
visibility to such discrepancy more effectively. Might be worth a sentence
or two. I guess if there hasn't been a report before (no idea), people
just don't do this in Postgres and so haven't been bitten by it at all
Or they do do these things but given the natural order of difference
between the two results quickly realize that they need to add the
parentheses.
I would maybe add to the first sentence in that section.
"""
Operator associativity conforms to mathematical conventions unless
otherwise noted in the description.
"""
That does beg the questions as to where one might find definitions for
"conventional order" and whether any other notes need to be added.
Pointing any of this out in a big highlighted comment block seems like
overkill.
I'm not seeing that there is enough benefit to merit changing the behavior
even in the name of consistency and adhering to the POLA. Maybe if we
could change the definition so that it is per-function as opposed to
per-symbol it would be worth considering - though likely not even then.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
On Tue, Dec 22, 2015 at 9:55 AM, Henrik Pauli <henrik.pauli@uhusystems.com>
wrote:On 22/12/15 17:00, Tom Lane wrote:
However, pointing the issue out somewhere near Table 9-2. Mathematical
Operators seems reasonable. The minimum change would just be to call it
out in the table entry itself:
Might well be enough, not sure. Some parts of the documentation do come
with little "Note" boxes in the text (can't quite remember an exact
example, but I seem to remember there being such), which increase
visibility to such discrepancy more effectively. Might be worth a sentence
or two. I guess if there hasn't been a report before (no idea), people
just don't do this in Postgres and so haven't been bitten by it at all
Pointing any of this out in a big highlighted comment block seems like
overkill.
Yeah, given the lack of other complaints, I think a parenthetical comment
in the table entry is sufficient. Done that way.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 28/12/15 18:11, Tom Lane wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
On Tue, Dec 22, 2015 at 9:55 AM, Henrik Pauli <henrik.pauli@uhusystems.com>
wrote:On 22/12/15 17:00, Tom Lane wrote:
However, pointing the issue out somewhere near Table 9-2. Mathematical
Operators seems reasonable. The minimum change would just be to call it
out in the table entry itself:Might well be enough, not sure. Some parts of the documentation do come
with little "Note" boxes in the text (can't quite remember an exact
example, but I seem to remember there being such), which increase
visibility to such discrepancy more effectively. Might be worth a sentence
or two. I guess if there hasn't been a report before (no idea), people
just don't do this in Postgres and so haven't been bitten by it at all​Pointing any of this out in a big highlighted comment block seems like
overkill.​Yeah, given the lack of other complaints, I think a parenthetical comment
in the table entry is sufficient. Done that way.regards, tom lane
Excellent, thank you :)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs