Re: SQL function parse error ? - Mailing list pgsql-sql

Please let me state again where i stand regarding this issue, apart from
tech stuff.
From the viewpoint of someone who has worked with databases for quite some
time, including postgresql (2yrs),
and is making a living out of it, -- that would be me :) -- it is a very odd
and unpleasant behaviour. That's a simple fact.
However, the feeling slips away in about 5 minutes or so, even if i'm
writing all db scripts by hand and have to pay attention
to this quite often. That's because i like pgsql, i enjoy compiling,
testing, tweaking configuration, trying to push the load
thru the roof and stuff like that. But that's me. I am not at all bothered
by this issue anymore.
What i'm saying is that i know that some of my colleagues, nice guys for
that matter, and good programmers, will come screaming
to me "what's with the b.s. error ?!?", and when i'll tell them that the sql
parser belives that's an inexisting operator, they'll start
cursing at it, just like i did.
For what it's worth, some policy should be enforced, because it shouldn't
matter how many spaces you put between the operator
and the operand, as writing SELECT * is the same as SELECT
*.
I rest my case.

Cheers,
=====
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.


----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Achilleus Mantzios" <achill@matrix.gatewaynet.com>
Cc: "Radu-Adrian Popescu" <radu.popescu@aldratech.com>;
<pgsql-sql@postgresql.org>
Sent: Thursday, January 09, 2003 5:57 PM
Subject: Re: [SQL] SQL function parse error ?


Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:
> On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>> Why is that ? Because the >$ does not exist, not in the default operator
>> list

> i think the parser is built with yacc, (not "from scratch code") so
> maybe finding if ">$" is in the specific DB's operators
> would require code that whould slower the whole parsing
> process (imagine what it means for performance).

There are a couple of good reasons why parsing strings into tokens does
not depend on looking to see which operators actually exist (as opposed
to which ones *could* exist per the defined rules for operator names):

1. It'd be impractical to detect whether the effective parsing rules are
complete or consistent, if they depend on the contents of database
tables that will vary from one installation to another.

2. The lexer and grammar stages of parsing cannot look into the database
state, because they have to be executable outside a transaction.
Otherwise we'd have problems with detecting/processing BEGIN, COMMIT,
ROLLBACK statements.

(Speed would probably be a significant issue too, though I don't have
any hard facts to back up that feeling.  We'd definitely have to abandon
the use of lex/flex tools to generate the lexing code.)

Because of these issues, the question of whether ">$" actually is
defined as an operator in a particular installation is irrelevant to
how we split character strings into tokens.  The only way we have to
adjust this behavior is by changing the rules about what an operator
name could be, for everyone.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command   (send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)