Обсуждение: 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.
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
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 8 > > Do 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.
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 tha= t >>> 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 somethi= ng >> 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 an= d > that's a reasonable problem there. That said, I guess the (few) users wi= th > 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 = 8 >> >> Do 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 senten= ce > 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 =E2=80=8BOr they do do these things but given the natural order of differen= ce 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. =E2=80=8BPointing any of this out in a big highlighted comment block seems = like overkill.=E2=80=8B 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. =E2=80=8B
"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
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 :)