Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 7B8FF475A1E
	for <pgsql-sql@postgresql.org>; Fri, 10 Jan 2003 09:27:03 -0500 (EST)
Received: from localhost.localdomain (unknown [65.217.53.66])
	by postgresql.org (Postfix) with ESMTP id A664A475925
	for <pgsql-sql@postgresql.org>; Fri, 10 Jan 2003 09:27:02 -0500 (EST)
Received: from thorn.mmrd.com (thorn.mmrd.com [172.25.10.100])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0AEiT6P010849;
	Fri, 10 Jan 2003 09:44:30 -0500
Received: from gnvex001.mmrd.com (gnvex001.mmrd.com [192.168.3.55])
	by thorn.mmrd.com (8.11.6/8.11.6) with ESMTP id h0AEQwj11674;
	Fri, 10 Jan 2003 09:26:59 -0500
Received: from camel.mmrd.com ([172.25.5.213]) by gnvex001.mmrd.com with SMTP
	(Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XX5J5DBF; Fri, 10 Jan 2003 09:26:56 -0500
Subject: Re: SQL function parse error ?
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
In-Reply-To: <000b01c2b888$79e18100$0600a8c0@rpopescu>
References: 
 <Pine.LNX.4.44.0301091723290.22067-100000@matrix.gatewaynet.com><777.1042127
	826@sss.pgh.pa.us>  <006301c2b7fc$41e58e40$0600a8c0@rpopescu>
	<1042145043.2007.31.camel@camel>
	<000b01c2b888$79e18100$0600a8c0@rpopescu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 10 Jan 2003 09:26:58 -0500
Message-Id: <1042208818.2008.83.camel@camel>
Mime-Version: 1.0
X-Virus-Scanned: by AMaViS new-20020517
X-Archive-Number: 200301/151
X-Sequence-Number: 11016

On Fri, 2003-01-10 at 04:13, Radu-Adrian Popescu wrote:
> 
> 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 !

At least you started out all nice and flowery...

> 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).
<snip>
> 
> There you go. Now go sit in the corner ! :)

Would an acceptable defense be that select*fromfoo doesn't work? Bah,
off to the corner I go...

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

But the point I was trying to make is that maybe the reason the answer
is no is that they don't support $ in operators. You'll note that a
clause like  mytime<now() works. Perhaps it's a quirk on my part that I
tend to want to know *why* something works the way it does before I go
about changing it. 

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

Would you suggest the parser should assume >$1 equals > $1? That seems
likely to break a lot of cases where >$ was being used. OTOH, if your
saying that support of >$1  is more important than support of >$ 1
that's a different argument. That's what you are saying (afaict) and
that's also the path that the developers have taken in trying to resolve
the issue. 

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

I think people were trying to explain to you the reasons for the current
behavior, at least that's what I was trying to attempt to do. 

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

yeah, my bad on that one. but your argument was still a non starter
because we aren't debating support for >              $1 (like in your
example), but support for >$1.  Actually you should be thanking in me,
since while my supposition was wrong, my example helps bolster your case
somewhat. :-)  

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

Maybe I need to re-read some of the other posts, but I think your taking
this too personally. My email was simply trying to help frame the issue
properly, because I saw you making an invalid argument in your own
defense. Furthermore you need to realize that when someone makes a claim
that a certain feature needs to work in a different fashion, or needs to
be added at the expense of another feature, that it is only natural and
a good thing that the proposal be given a little scrutiny to make sure
it stands up. At this point yours does so in my book, though I still
would like to see answered is whether oracle or others support >$ as an
operator, or if the sql spec has anything to say on the matter. 

Robert Treat