Date: Thu, 9 Jan 2003 09:00:31 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>,
	Radu-Adrian Popescu <radu.popescu@aldratech.com>,
	<pgsql-sql@postgresql.org>
Subject: Re: SQL function parse error ? 
In-Reply-To: <777.1042127826@sss.pgh.pa.us>
Message-ID: <20030109085635.I92199-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 9 Jan 2003, Tom Lane wrote:

> 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).

> 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.

Although the rules could be similar to those for + and - at the end of
operator strings (no $ at the end of an operator unless it contains
characters not normally in SQL92 operators).  I'm not sure that
behavior is sensible either, but if someone wanted to
do it for their own installation it's about a 2 line patch.