Re: SQL function parse error ? - Mailing list pgsql-sql

From Radu-Adrian Popescu
Subject Re: SQL function parse error ?
Date
Msg-id 000b01c2b888$79e18100$0600a8c0@rpopescu
Whole thread Raw
In response to Re: SQL function parse error ?  (Achilleus Mantzios <achill@matrix.gatewaynet.com>)
Responses Re: SQL function parse error ?
List pgsql-sql
Robert, my dear fellow...

How about checking your facts before contradicting anyone ? Shame on you !
Have you actually tried to do a SELECT* from foo ? Pathetic !
Try it out, if that won't work on Oracle, MSSQL, PostgreSql I'll buy
everyone on this list a chase of Crystal.
Robert, even   select*from errors;
works on all three of them ! (Sorry about the colors, pasted from TOAD).
Here's psql for instance:

db=# SELECT * from prod ;id |     name     | price  | group_id
----+--------------+--------+---------- 4 | some product |  55.00 |        3 6 | MyPC         | 300.00 |        3
(2 rows)
db=# SELECT*from prod ;id |     name     | price  | group_id
----+--------------+--------+---------- 4 | some product |  55.00 |        3 6 | MyPC         | 300.00 |        3
(2 rows)

There you go. Now go sit in the corner ! :)
Also, as I tried to make it quite clear, the point is not whether Oracle or
mysql allow the
use of $ in operators, but whether you have to write cumbersome syntax to
get things working. And the
answer is definitely _no_.
My point here is that common sense (and the use of $1, $2,... with operator
> is going
come up a lot, opposed to the user-defined operator >$, which takes
precedence when parsing a special
case of the SQL command) should prevail over backwards compat. Loot at C++
for instance, the standard
broke a lot of C++ apps that were written poorly.

It seems that - strangely - instead of trying to acknowledge not necessarily
incorrect but awkward behavior,
some people on this list have tried to put me down.
What's even more scary is receiving answers like "SQL queries are like bash
commands",
or "SELECTXFROMY is not valid - whitespace matters" (when in fact I was
simply pointing out that
i==3 and i == 3 should be parsed alike), or Robert's claim that SELECT* from
... is invalid SQL.

The good news is some people seem to have gotten the point and are doing
something about it - and this
makes me feel like maybe, maybe I've helped the community just a little bit.
After all, we all want to see
postgresql up there where it belongs.

That being said, I do hope that superficial replies trying to prove me wrong
will stop, as they actually don't help
anyone.

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

----- Original Message -----
From: "Robert Treat" <xzilla@users.sourceforge.net>
To: "Radu-Adrian Popescu" <radu.popescu@aldratech.com>
Cc: "Achilleus Mantzios" <achill@matrix.gatewaynet.com>; "Tom Lane"
<tgl@sss.pgh.pa.us>; <pgsql-sql@postgresql.org>
Sent: Thursday, January 09, 2003 10:44 PM
Subject: Re: [SQL] SQL function parse error ?


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







pgsql-sql by date:

Previous
From: Chad L
Date:
Subject: Table Design Questions
Next
From: "Radu-Adrian Popescu"
Date:
Subject: Re: insert rule doesn't see id field