Re: Vote totals for SET in aborted transaction

Mike Mascari <mascarm@mascari.com>

From: Mike Mascari <mascarm@mascari.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: "Marc G. Fournier" <scrappy@hub.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-04-25T17:16:51Z
Lists: pgsql-hackers
Bruce Momjian wrote:
> 
> Marc G. Fournier wrote:
> >
> > Just curious here, but has anyone taken the time to see how others are
> > doing this?  For instance, if we go with 1, are going against how everyone
> > else handles it?  IMHO, its not a popularity contest ...
> 
> Yes, good point.  I don't know that they use SET, but if they do, we
> should find out how they handle it, though I doubt they have thought
> through their SET handling as well as we have.  My guess is that they do
> 3, honor all SETs.

Connected to:
Oracle8 Enterprise Edition Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production

SQL> SELECT TO_CHAR(SYSDATE) FROM DUAL;

TO_CHAR(S
---------
25-APR-02

SQL> COMMIT;

Commit complete.

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY MM DD';

Session altered.

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT TO_CHAR(SYSDATE) FROM DUAL;

TO_CHAR(SY
----------
2002 04 25

Of course, with Oracle, the only operations which can be rolled back are
INSERTs, UPDATEs, and DELETEs (DML statements). A long time ago, on a
planet far, far away, I argued that PostgreSQL should follow Oracle's
behavior in this regard. I stand corrected. The ability to rollback DROP
TABLE is a very nice feature Oracle doesn't have, and to remain
consistent, I agree with all of those that have voted for #1.

Mike Mascari
mascarm@mascari.com