Oh, there isn't really much change. The minus is passed standalone
as it always was. The only thing is that currently in numbers with unary
minus it gets coerced not in lexer, but in parser in doNegate().
I wonder why that hasn't been done earlier - especially considering
that doNegate() existed long before my, hmm, fiddling.
To tell the truth, there is some ambiguity in various operators.
That ambiguity is stemming from Postgres's type-extension system.
Consider this: SELECT 3+-2; What would you expect from that? I
personally would expect the result of 1. But it produces an error,
because '+-' is treated as some user-defined operator, which is
not true. Such innocent expression as SELECT --2 puts Postgres in
daze - it (psql) waits for 'completion' of such query (it treats
symbols '--' as comment start :-) See? There are more pitfalls
beside minus coercing :-)
This all was done to clean up the code and 'straighten' the parser.
There was a performance breaker, officially called AFAIR 'variable
trailing context'.
Thomas Lockhart wrote:
>
> There are several cases which need to be handled (I'm doing this from
> memory, so may miss a few):
>
> o Positive and negative numbers as standalone arguments, with and
> without spaces between the "-" and the digits.
>
> o Positive and negative numbers as first arguments to binary
> operators, with and without spaces at all possible places.
>
> o Positive and negative numbers as second arguments to binary
> operators, or as arguments to unary operators.
>
> o Positive and negative numbers in the presence of operators
> containing minus signs, including a trailing minus sign where
> possible.
>
> 'taint easy to do it completely right. Perhaps trying to do less in
> the scanner is the right thing to do, but istm that it may put
> restrictions on the grammar which are not currently there. Not a good
> trade for a longer query length...
--
Leon.
