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

Re: Vote totals for SET in aborted transaction

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>,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 15:51:34
Message-ID: 3CCD6C06.64C2A73@fourpalms.org (view raw or flat)
Thread:
Lists: pgsql-hackers
...
> Agreed, very non-intuitive.  And can you imagine how many applications
> we would break.

What is non-intuitive about it? What it *does* do is free the programmer
from worrying about side effects which *do* break applications.

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.

And the number of current applications "broken"? None, as a starting
point ;)

                  - Thomas

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-29 15:53:29
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Thomas LockhartDate: 2002-04-29 15:44:26
Subject: Re: Vote totals for SET in aborted transaction

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