From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Radu-Adrian Popescu <radu.popescu@aldratech.com>
Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: SQL function parse error ?
Date: Thu, 9 Jan 2003 07:47:29 -0800 (PST)
Message-ID: <20030109073958.B91463-100000@megazone23.bigpanda.com> (raw)
In-Reply-To: <003301c2b7f5$34b6c920$0600a8c0@rpopescu>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: sszabo@megazone23.bigpanda.com, radu.popescu@aldratech.com, achill@matrix.gatewaynet.com
Subject: Re: SQL function parse error ?
In-Reply-To: <20030109073958.B91463-100000@megazone23.bigpanda.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox