Re: implied FROM - Mailing list pgsql-sql

From Matt Mello
Subject Re: implied FROM
Date
Msg-id 59964.24.243.219.116.1051883093.squirrel@earth.spaceship.com
Whole thread Raw
In response to Re: implied FROM  (Tomasz Myrta <jasiek@klaster.net>)
Responses Re: implied FROM  (Bruno Wolff III <bruno@wolff.to>)
Re: implied FROM  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-sql
Tomasz Myrta said:
> <cut>
> Some people
> said,  that it is very useful inside update queries. The conclusion was
> this  behaviour should stay as it is.

I see.  I would have to disagree with those people.

It seems that if you mistype an SQL statement, PG should except rather than
proceeding with what could potentially be a very long / very wrong
transaction.  If table "store" has 2 billion entries, then my resultset is
going to be 2 billion rows, even though I was expecting ONE, and since I am
using JDBC, every single row will have to be sent and stored in ram before I
can EVEN KNOW that there was a problem.  With a sufficiently large data set,
this will probably cause an out of memory exception, which will eventually
let me know there was a problem, but since I might get the same error on
other threads/processes before this one, I won't know WHY I ran out of ram
suddenly.  I'm sure there are many other bad things that could happen via
this "feature", but this is just the first one I could think of.

This "feature" violates the law of least surprise (or whatever you call it):
No first-time user of PG who knows SQL would expect this to happen.  And
furthermore, you never want a program to second-guess and you go off and
spend CPU cycles and valuable ram doing something.  That is why so many
people hate Microsoft products.  It is an MS-ism to try to make "computers
for dummys", however PG shouldn't be for dummys, but should be for people
who know SQL.  I am very worried that some people find this feature "very
useful inside update queries".

We should at least have the ability to change a PG setting to say that we DO
NOT WANT PG to try to second guess us ('set FORDUMMYS = false', or
whatever). In my mind, this "feature" is a violation of the spirit of SQL.
I wish I was on this list for the "vote" everyone took on this.

Please, great elephant gurus, please, please, please do not add any more
features like this one without giving me the power to turn it off.  I don't
want my mistakes to be turned into opportunities for my system to completely
crash.

--
Matt Mello



pgsql-sql by date:

Previous
From: Rado Petrik
Date:
Subject: What is bad in this query ?
Next
From: Achilleus Mantzios
Date:
Subject: Re: What is bad in this query ?