Since you can overload and define new operators, the parser must - at some
point in time - lookup the operator definition.
It seems to me (but this is just an ideea), that the rules should go like
this :
...
check >$ is a defined operator
if true, it is applied to left side and 1, in my example.
if not, check that $1 is a valid expression (which it is) ...go on...
This should do the trick. And you would be able to write leftSide>$$1 and
would get the >$ operator applied to leftSide and $1.
And leftSide>&1 would apply the >& operator to 1, and my code would then
have a [very suble] bug.
Simply put, operator precedence over local identifiers/parameters, which i
belive is a de facto standard in most languages (no flames please !)
:)
Cheers,
=====
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
----- Original Message -----
From: "Achilleus Mantzios" <achill@matrix.gatewaynet.com>
To: "Radu-Adrian Popescu" <radu.popescu@aldratech.com>
Cc: <pgsql-sql@postgresql.org>
Sent: Thursday, January 09, 2003 9:29 PM
Subject: Re: [SQL] SQL function parse error ?
On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:
>
>
> Why is that ? Because the >$ does not exist, not in the default operator
> list (also there is no operator defined
> using $ anywhere within). And because whitespacing the code solves the
> problem, which is rather thin, i must say.
>
Radu-Adrian,
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).
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com mantzios@softlab.ece.ntua.gr
