Date: Thu, 9 Jan 2003 07:47:29 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Radu-Adrian Popescu <radu.popescu@aldratech.com>
Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>,
	<pgsql-sql@postgresql.org>
Subject: Re: SQL function parse error ?
In-Reply-To: <003301c2b7f5$34b6c920$0600a8c0@rpopescu>
Message-ID: <20030109073958.B91463-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 9 Jan 2003, Radu-Adrian Popescu wrote:

> 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 !)
[It's only an issue when you can define

IIRC there are issues with allowing table lookups in parse phase which the
above would require (otherwise you couldn't find out if >$ is defined).  I
believe it currently just makes an operator out of the longest sequence of
valid operator characters.  Also, I'm not sure how you'd get the above to
work with bison which is a fairly big deal.

If you can write a solution that meets all of the arguments that were made
the last time there was a discussion about it, it'd probably be accepted.