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

Re: Vote totals for SET in aborted transaction

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,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 17:47:54
Message-ID: 1020102474.27495.46.camel@taru.tm.ee (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2002-04-29 at 18:20, Tom Lane wrote:
> Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> > Rather than dismissing this out of hand, try to look at what it *does*
> > enable. It allows developers to tune specific queries without having to
> > restore values afterwards. Values or settings which may change from
> > version to version, so end up embedding time bombs into applications.
> 
> I think it's a great idea. 

So do I. 

And I also think that this will solve the original issue, which iirc was
rolling back SET TIMEOUT at ABORT.

If we have LOCAL SET, there is no need to have any other mechanism for
ROLLING BACK/COMMITing SET's - SET and DML can be kept totally separate,
as they should be based on fact that SET does not directly affect data.

--------------
Hannu


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-29 18:05:39
Subject: Folding variable.c into the GUC structure, redux
Previous:From: Hannu KrosingDate: 2002-04-29 17:39:25
Subject: Re: Vote totals for SET in aborted transaction

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