Message-ID: <001101c2b7f0$950c98e0$0600a8c0@rpopescu>
From: "Radu-Adrian Popescu" <radu.popescu@aldratech.com>
To: <pgsql-sql@postgresql.org>
References: <008f01c2b7d0$3733fdf0$0600a8c0@rpopescu>
	<3E1D6362.80701@klaster.net>
	<00a501c2b7dc$a5c626b0$0600a8c0@rpopescu>
	<3E1D77B3.4000503@klaster.net>
Subject: Re: SQL function parse error ?
Date: Thu, 9 Jan 2003 17:05:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Thomas, this line of conversation is not quite what one would expect...

I do read the postgresql docs when in run into trouble. And yes, i do know
there is such a thing as
operator overloading.

What i'm saying here, and i belive to be right, is that writing a piece of
code such as
    table.columnName>$3
should not yeald an error.

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.

Consider you would create operator >&. How should the parser interpret the
above piece of code ?
Operator or parameter ? If such a distinction is defined on strong grounds,
i have failed to see it stated anywhere
in the docs. Until then, based on experience with SQL code from alot of
dbms, c++ (operators, overloading, etc)
and php (where $name is a variable), i do belive the error reported is bogus
and unjustified.

As i was able to see from 7.3.1 docs, part of the operator documentation is
written by Tom Lane.
Perhaps some insight from the people in charge with SQL functions and/or
operators might help clear this issue.

Cheers,
=====
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.

----- Original Message -----
From: "Tomasz Myrta" <jasiek@klaster.net>
To: "Radu-Adrian Popescu" <radu.popescu@aldratech.com>
Cc: <pgsql-sql@postgresql.org>
Sent: Thursday, January 09, 2003 3:22 PM
Subject: Re: [SQL] SQL function parse error ?


Radu-Adrian Popescu wrote:

> I'm perfectly aware of the fact that a space solves the issue here.
>
> What I'm saying is that it is not natural nor common to take some
> whitespace
> into
> account when parsing, since this is not bash language, nor python, as it
> shouldn't be !
> This is SQL, and people who are using PostgreSql write SQL, not
> whitespace-sensitive SQL, bash or whatever.
>
> And besides, like I have already pointed out, look at php's language
> parser
> (behavior, not source) :
> the statement if(100>$a) is perfectly legal, as it should be.
> Is there any operator named >$ ?
>
> Anyone who has used anything from Mysql to Oracle will get quite
> annoyed on
> this one.
>
> Hope the people in charge of the parser will get to the bottom of this...
> ... and please forgive my caustic tone.
>
> =====
> Radu-Adrian Popescu
> CSA, DBA, Developer
> Aldratech Ltd.

I think you are absolutely wrong.
It is possible in Postgresql to overload operators and if you want, you
can create operator named ">$".

There is a lot of useful things in postgresql documentation. If you read
it, you could find this:

 >CREATE OPERATOR defines a new operator, name. The user who defines an
 >operator becomes its owner.
 >The operator name is a sequence of up to NAMEDATALEN-1 (31 by default)
 >characters from the following list:
 >+ - * / < > = ~ ! @ # % ^ & | ` ? $

Regards,
Tomasz Myrta


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly