On Thu, 25 Apr 2002, Mike Mascari wrote:
> 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.
Okay, based on this, I'm pseudo-against ... I think, for reasons of
reducing headaches for ppl posting, there should be some sort of 'SET
oracle_quirks' operation that would allow for those with largish legacy
apps trying to migrate over to do so without having to check for "odd"
behaviours like this ...
Or maybe "SET set_rollbacks = oracle"? with default being #1 as discussed
...
