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
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 |