Re: SQL function parse error ?

Achilleus Mantzios <achill(at)matrix(dot)gatewaynet(dot)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