From: | Adrian 'Dagurashibanipal' von Bidder <avbidder(at)fortytwo(dot)ch> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: COMMIT in PostgreSQL |
Date: | 2002-07-19 15:00:43 |
Message-ID: | 1027090843.8993.34.camel@atlas |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2002-07-19 at 15:48, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > On Sat, Jul 20, 2002 at 03:03:02PM +0300, stefan(at)extum(dot)com wrote:
> >> thanks a lot all for comments. So in PostgreSQL each query is a
> >> transaction ?
>
> > If you want them that way. If you want to combine them into one transaction,
> > you use BEGIN.
>
> Right; otherwise you get the sort of behavior that some other databases
> call auto-commit.
>
> While we can't change this without breaking huge amounts of client code,
> there has been talk of offering a parameter setting that could be
> changed to support the SQL-standard behavior (which could be thought of
> as auto-BEGIN in Postgres terms: any statement implicitly causes a
> BEGIN, and then you stay in that transaction until you explicitly say
> COMMIT).
How much client code would break if pg would start-up in 'autocommit',
and revert to standard SQL after receiving the first 'COMMIT'?
(Supposing - I don't know that - that standard SQL but an implicit BEGIN
at statements issued after a COMMIT).
Benefits: adapting SQL code that excepts standard behaviour would be
easy to fix by just requiring to enter a BEGIN upon opening the
connection.
Just a thought.
cheers
-- vbi
--
secure email with gpg http://fortytwo.ch/gpg
From | Date | Subject | |
---|---|---|---|
Next Message | Stephane Bortzmeyer | 2002-07-19 15:02:11 | Re: Looking for types: phone number, email addresses |
Previous Message | Jan Wieck | 2002-07-19 14:51:46 | Re: Looking for types: phone number, email addresses |