Tom Lane wrote:
> Michael Glaesemann <grzm@seespotcode.net> writes:
>> What use case are you envisioning? Just saving ... *counts ... 14
>> keystrokes in this case? (I'm not saying there *isn't* a use case. I
>> just don't see a big benefit here.)
>
> Quite aside from the compatibility and how-useful-is-it-really
> arguments, I think this'd be a bad idea in the abstract. SQL is not one
> of those languages that assigns semantic significance to the shape of
> whitespace [1]. We should NOT introduce any such concept into psql,
> because it'd fundamentally break the lexical structure of the language.
> To take just one example of the difficulties you'd get into, consider
>
> select 1; select
> 2; select 3;
>
> How many transactions is that exactly? And on what grounds are you
> deciding?
Well, my use case was that I was doing a quick batch process that had
about half a dozen statements in a row that were insert/update/delete.
If I had forgotten to type by begin; , I could have a problem with
consistency of various things if one in the middle failed.
I understand that this is completely a sugar feature and I am not
actually arguing for as much as I am saying, "Hey this was an
interesting thought".
>
> (No, I don't like python. Why do you ask? ;-))
Heh... I happen to like Python quite a bit:
But even in Python you can do:
select 1; select 2; select 3;
From an implementation perspective I would suggest that if the line has
a carriage return then it doesn't behave as a single transaction.. e.g;
BEGIN; SELECT 1; SELECT 2;
COMMIT;
Would be the same as:
SELECT 1; SELECT 2;
But not the same as:
SELECT 1;
SELECT 2;
Egad... forget I even mentioned it... These looks like a whole lot of
pgsql-novice posts having to be answerd.
Thanks for entertaining me though.
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
> [1] Mostly. There's the infamous continued-string-literal construct...
>
--
=== The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency:
+1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/