Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id B71F1476785 for ; Thu, 9 Jan 2003 10:37:40 -0500 (EST) Received: from aldratech.com (unknown [213.154.158.58]) by postgresql.org (Postfix) with ESMTP id 868E5476599 for ; Thu, 9 Jan 2003 10:37:12 -0500 (EST) Received: from rpopescu ([192.168.0.6]) by aldratech.com for with eXtremail; Thu, 9 Jan 2003 18:38:06 +2GMT Message-ID: <003301c2b7f5$34b6c920$0600a8c0@rpopescu> From: "Radu-Adrian Popescu" To: "Achilleus Mantzios" Cc: References: Subject: Re: SQL function parse error ? Date: Thu, 9 Jan 2003 17:38:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/129 X-Sequence-Number: 10994 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" To: "Radu-Adrian Popescu" Cc: 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