Skip site navigation (1) Skip section navigation (2)

Re: Vote totals for SET in aborted transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-29 16:51:07
Message-ID: 29601.1020099067@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
>> I can certainly think of uses for a local-effects flavor of SET.
>> But I don't want that to be the only flavor.

> Right. And there was no suggestion that there be so; the original
> proposal used "BEGIN/END blocks" to differentiate the usage.

Right.  But I don't like the notion of making SET's behavior vary
depending on context.  I think it's better both from a user-friendliness
standpoint and from a compatibility standpoint to use different syntaxes
to indicate the desired behavior.

> Think about
> SET SESSION... as a possible syntax to completely decouple the behaviors
> if an explicit notation is desired.

Well, if you accept the notion of distinguishing it by syntax, then
we're down to arguing about which case should be associated with the
existing syntax.  And I think persistent has to win on compatibility
grounds.  (Doesn't the Perl DBI driver also do the automatic-begin
thing?  Breaking all Java apps and all Perl apps that issue SETs is
rather a big compatibility problem IMHO...)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-29 17:04:52
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Olivier PRENANTDate: 2002-04-29 16:46:10
Subject: Re: clarification of timestamp

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group