Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Postgres' lexer

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Leon <leon(at)udmnet(dot)ru>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postgres' lexer
Date: 1999-09-01 02:19:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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;
(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

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 1999-09-01 02:30:44
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
Previous:From: Thomas LockhartDate: 1999-09-01 01:51:02
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group