Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> > If at all, SET commands should behave like everything else.
> > If done inside a transaction, they have to rollback.
>
> I have thought of a scenario that may be sufficient to justify fixing
> SETs to roll back on transaction abort. Consider
>
> BEGIN;
>
> CREATE SCHEMA foo;
>
> SET search_path = 'foo, public';
>
> ROLLBACK;
>
> As the code stands, this will leave you with an invalid search path.
> (What's worse, if you now execute CREATE TABLE, it will happily create
> tables belonging to the vanished namespace foo. Everything will seem
> to work fine ... until you try to find those tables again in a new
> session ...)
>
> It seems clear to me that SET *should* roll back on abort. Just a
> matter of how important is it to fix.
That was my point, that having SET work pre-abort and ignored post-abort
is broken itself, whether we implement timeout or not. Before we had
tuple-reading SET variables, it probably didn't matter, but now with
schemas, I can see it is more of an issue.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
