Re: Vote totals for SET in aborted transaction
От | Mike Mascari |
---|---|
Тема | Re: Vote totals for SET in aborted transaction |
Дата | |
Msg-id | 3CC83A03.554E3AF1@mascari.com обсуждение исходный текст |
Ответ на | Re: Vote totals for SET in aborted transaction (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Vote totals for SET in aborted transaction
|
Список | 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
В списке pgsql-hackers по дате отправления: