Re: BUG #13829: Exponentiation operator is left-associative

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