Thomas Lockhart wrote:
> I'll make the (perhaps incorrect) claim that the current behavior is
> about right for numeric constants (common cases involving various
> whitespace possibilities work about right once everything is through
> the parser). (The "+-" operator is a good unusual case to focus on,
> and we may conclude that it isn't done right at the moment.) Where
> things happen in the parser can change. If the current behavior can't
> be reconciled with improved behaviors with other non-constant
> expressions, then maybe it should be sacrificed, but not until we try
> hard to improve it, rather than disallow it...
Suppose you parse a***-b (where *** are any operator-like symbols)
as (a) *** - (b). Hence you parse a?-b as (a) ? - (b). No good.
Solution? No clean solution within horizon - must then have hardwired
list of operators somwhere in pasrer. If we could dream of changing
?- operator ... ;) But we can't. Even your model of system which
sticks uminus to number isn't fit for type-extension system. Imagine
there is crazy user some place out there who wants to define operator
like +- or #- . It doesn't seem to be senseless - if Postgres itself
has ?- operator, it then could live with my homegrown %- operator!
And then suppose that the second argument to that operator is number.
See the pitfall?
The only possible thing seems to be to state in documentation that we
have a peculiar type-extension system which is biased towards long
operators - when it sees long operator string, it swallows it as a whole.
Thus - users, use spaces where needed! This is the way to introduce
type-extension ideology throughout the system from parser onwards.
This ideology could be the guiding light in parser matters
(there is now lack thereof).
--
Leon.
