RE: [HACKERS] Postgres' lexer

Leon wrote:
>> Ok. Especially if there are more unary operators (I always wondered
>> what unary % in gram.y stands for :) it is reasonable not to make
>> a special case of uminus and slightly change the old behavior. That
>> is even more convincing that constructs like 3+-2 and 3+-b were
>> parsed in different way, and, what is worse, a>-2 and a>-b also
>> parsed differently. So let us ask the (hopefully) last question:
>> Thomas (Lockhart), do you agree on always parsing constructs like
>> '+-' or '>-' as is, and not as '+' '-' or '>' '-' ?
This construct doesn't always make sense. It should only be recognised as a
'>-' if that operator exists, otherwise it should be either generate an
error (which is reasonable because of the ambiguity that it creates (not for
this operator, but for the general case)), or try to complete (if that's
possible). I have a bit of a problem with reading this: a > -2 correctly,
while not reading this: a>-2 correctly, because that implies that you are
using the space as a precedence operator. This should be done by braces.
This: a > (-2) is totally unambiguous, spaces or no spaces.

Perhaps there is a general case for where unary operators are allowed to
appear, and we can use this, e.g.: they can only appear at the beginning of
an expression, or immediately after another operator (ignoring spaces).
This means that >- will be scanned as an operator if it exists, or a >
followed by a unary minus if >- doesn't exist as an operator. And this
removes some ambiguity, because now we have a defined rule: if the - doesn't
appear at the beginning of an expression, or immediately (ignoring spaces)
after another operator, then it must be a binary minus.

MikeA