Re: Vote totals for SET in aborted transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
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:09:52
Message-ID: 29764.1020100192@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> And I also think that this will solve the original issue, which iirc was
> rolling back SET TIMEOUT at ABORT.

It does provide a way to deal with that problem. But we still have the
example of

begin;
create schema foo;
set search_path = foo;
rollback;

to mandate changing the behavior of plain SET to roll back on error.

> 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.

That can only work if you have no connection at all between SETs and
data that is in the database; which seems to me to be a rather large
restriction on what SET can be used for. (In particular, search_path
couldn't be treated as a SET variable at all; we'd have to invent some
other specialized command for it.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2002-04-29 17:14:43 Re: Vote totals for SET in aborted transaction
Previous Message Tom Lane 2002-04-29 17:04:52 Re: Vote totals for SET in aborted transaction