Andrew Gierth writes:
> Here's what I will push unless there's something important I missed.
Stylistic nitpick: I don't especially like "continue" as the body of
a for-loop. How about instead of this:
for (nchars--;
nchars > 1 &&
(yytext
Here's what I will push unless there's something important I missed.
I split the regression tests between create_operator.sql and
polymorphism.sql, because => is really "named argument syntax" rather
than an operator as such, and polymorphism.sql is where the existing
tests were for that.
I tried
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> * Some regression tests exercising these code paths might be a
> Tom> good thing.
> Agreed. Any preferences where they should go?
There's not really a "lexer/grammar" test script. Maybe you could
drop it into create_operator.sql, espec
> "Tom" == Tom Lane writes:
>> Patch attached.
>> This fixes two bugs: first the mis-lexing of two-char ops as mentioned
>> originally; second, the O(N^3) lexing time of strings of - or +
>> characters is reduced to O(N^2) (in practice it's better than O(N^2)
>> once N gets large because
Andrew Gierth writes:
> "Andrew" == Andrew Gierth writes:
> Andrew> I guess the fix is to extend the existing special case code
> Andrew> that checks for one character left after removing trailing [+-]
> Andrew> and also check for the two-character ops "<>" ">=" "<=" "=>"
> Andrew> "!=".
> P
> "Andrew" == Andrew Gierth writes:
Andrew> Patch attached.
Andrew> This fixes two bugs:
I'm going to split this into two patches, since the O(N^3) fix can be
backpatched further than the operator token fix; the latter bug was
introduced in 9.5 when operator precedences were corrected, wh
> "Andrew" == Andrew Gierth writes:
Andrew> select f(a =>-1); -- ERROR: column "a" does not exist
Andrew> I guess the fix is to extend the existing special case code
Andrew> that checks for one character left after removing trailing [+-]
Andrew> and also check for the two-character ops
Currently in PG, the precedence of = and <> is supposed to be equal, and
the precedence of unary - is very high.
So, (true=1 between 1 and 1) parses as ((true)=(1 between 1 and 1)),
and (true=-1 between 1 and 1) parses as ((true)=((-1) between 1 and 1)).
All good so far.
(true<>-1 between 1 and 1
