Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 4FB8D475CB1 for ; Thu, 9 Jan 2003 06:12:29 -0500 (EST) Received: from aldratech.com (unknown [213.154.158.58]) by postgresql.org (Postfix) with ESMTP id DB8F24758C9 for ; Thu, 9 Jan 2003 06:12:27 -0500 (EST) Received: from rpopescu ([192.168.0.6]) by aldratech.com for with eXtremail; Thu, 9 Jan 2003 14:13:16 +2GMT Message-ID: <008f01c2b7d0$3733fdf0$0600a8c0@rpopescu> From: "Radu-Adrian Popescu" To: Subject: SQL function parse error ? Date: Thu, 9 Jan 2003 13:14:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C2B7E0.FAB0E710" 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/120 X-Sequence-Number: 10985 This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C2B7E0.FAB0E710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ! There is a strange behaviour in the SQL function parser (haven't tested thi= s with the plpgsql lang) when using standard operators and function parameters. Take the following for example: create or replace function testfunc1(int) returns setof test as ' select * from test where age>$1; ' language sql; This yealds the following error, which frankly is kind of too much : ERROR: Unable to identify an operator '>$' for types 'integer' and 'intege= r' I strongly belive the parser is a bit keen on interpreting the >$ sequence = as an operator. Take for instance php, where all variables start with $; " = 100>$foo " is quite valid ! The error goes away of course when rewriting it as " age > $1". I'm afraid that taking whitespace into consideration when parsing a languag= e is not the way to do it, except when it's python, of course :) Hope this, helps, Regards,=20 =3D=3D=3D=3D=3D Radu-Adrian Popescu CSA, DBA, Developer Aldratech Ltd. ------=_NextPart_000_008C_01C2B7E0.FAB0E710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello !

There is a strange behaviour in the SQL fu= nction=20 parser (haven't tested this with the plpgsql lang) when using standard=20 operators

and function parameters.

Take the following for example:

create or replace fun= ction=20 testfunc1(int) returns setof test as
'
select * fr= om=20 test where age>$1;
'

language sql;

Th= is yealds the=20 following error, which frankly is kind of too=20 much :

ERROR: Unable t= o identify=20 an operator '>$' for types 'integer' and 'integer'

I strongly belive the parser is a bit keen= on=20 interpreting the >$ sequence as an operator. Take for instance php, wher= e all=20 variables start with $; " 100>$foo "<= /DIV>

is quite valid !

The error goes away of course when rewriti= ng it as=20 " age > $1".

I'm afraid that taking whitespace into=20 consideration when parsing a language is not the way to do it, except when = it's=20 python, of course :)

Hope this, helps,

Regards,
=3D=3D=3D=3D=3D
Radu-Adria= n Popescu
CSA,=20 DBA, Developer
Aldratech Ltd.

------=_NextPart_000_008C_01C2B7E0.FAB0E710--