Re: [HACKERS] Postgres' lexer

> 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.

For good reasons. See below :(

> To tell the truth, there is some ambiguity in various operators.
> That ambiguity is stemming from Postgres's type-extension system.

There is the possibility for ambiguity. But it is our responsibility
to minimize that ambiguity and to make a predictable system, in the
presence of Postgres' unique and valuable features such as type
extension. imho this is more important than, for example, allowing
infinite-length queries.

> 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.

That is part of my concern here. The current behavior is what you say
you would expect! Your patches change that behavor!!

postgres=> select 3+-2;
?column?
--------
1
(1 row)

> 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 :-)

There are some well-defined features of SQL92 which we try hard to
support; the comment convention is one of them. That is a special case
and shouldn't confuse the issue here; we'll need a different test case
to make the point for me...

> This all was done to clean up the code and 'straighten' the parser.
> There was a performance breaker, officially called AFAIR 'variable
> trailing context'.

Sorry, what is the performance penalty for that feature, and how do we
measure that against breakage of expected, predictable behavior?
Please quantify.

So far, I'm not a fan of the proposed change; we're giving up behavior
that impacts Postgres' unique type extension features for an
arbitrarily large query buffer (as opposed to a generously large query
buffer, which can be accomplished just by changing the fixed size).

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California