Re: SQL function parse error ?

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Radu-Adrian Popescu <radu(dot)popescu(at)aldratech(dot)com>
Cc: Achilleus Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-sql(at)postgresql(dot)org
Subject: Re: SQL function parse error ?
Date: 2003-01-09 20:44:03
Message-ID: 1042145043.2007.31.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Thu, 2003-01-09 at 11:29, Radu-Adrian Popescu wrote:
> What i'm saying is that i know that some of my colleagues, nice guys for
> that matter, and good programmers, will come screaming
> to me "what's with the b.s. error ?!?", and when i'll tell them that the sql
> parser belives that's an inexisting operator, they'll start
> cursing at it, just like i did.
>

Does oracle or mysql or whichever db you like allow the use of $ in user
defined operators? If so, how do they know the difference?

For what it's worth, some policy should be enforced, because it shouldn't
> matter how many spaces you put between the operator
> and the operand, as writing SELECT * is the same as SELECT
> *.
> I rest my case.
>

Thats an invalid comparison. The problem is not that foo > $1
doesn't work, as your example put forth. The problem is that foo>$1
doesn't work, which by comparison would be SELECT* which would also not
work.

Robert Treat

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Ron Peterson 2003-01-09 21:50:56 Re: insert rule doesn't see id field
Previous Message dev 2003-01-09 19:54:04 Re: insert rule doesn't see id field