> Tom Lane <tgl@sss.pgh.pa.us> writes:
> Mike Mascari <mascarm@mascari.com> writes:
> > Well, I agree that it would be GREAT to be able to rollback DDL
> > statements.  However, at the moment, failures during a transaction
while
> > DDL statements occur usually require direct intervention by the user
(in
> > the case of having to drop/recreate indexes) and often require the
services
> > of the DBA, if filesystem intervention is necessary (i.e., getting rid
of
> > partially dropped/created tables and their associated fileystem
> > files).
> 
> And forced commit after the DDL statement completes will improve that
> how?

Because 99% of  the instances of index and data corruption I've seen
have come from rolled-back DDL statements - usually because the on
disk representation no longer matches the system catalogue. A forced 
commit on DDL changes against tables and indexes with access 
exclusive locks will make that operation as close to "atomic" as
possible...

> As a user I'd be pretty unhappy if "SELECT ... INTO" suddenly became
> "COMMIT; SELECT; BEGIN".  Not only would that mean that updates made
> by my transaction would become visible prematurely, but it might also
> mean that the SELECT retrieves results it should not (ie, results from
> xacts that were not committed when my xact started).  Both of these
> things could make my application logic fail in hard-to-find, hard-to-
> reproduce-except-under-load ways.

What does ORACLE do here?

> 
> So, although implicit commit might look like a convenient workaround at
> the level of Postgres itself, it'd be a horrible loss of reliability
> at the application level.  I'd rather go with #1 (hard error) than
> risk introducing transactional bugs into applications that use Postgres.
> 
> 
> > Since ORACLE has 70% of the RDBMS market, it is the de facto standard
> 
> Yes, and Windows is the de facto standard operating system.  I don't use
> Windows, and I'm not willing to follow Oracle's lead when they make a
> bad decision...
> 
> 			regards, tom lane

So I guess I should file away my other suggestion to use DCOM as 
the object technology of choice instead of CORBA? ;-)






Fri, 26 Nov 1999 14:48:20 -0500
"Mike Mascari" <mascarm@mascari.com>
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions 
On Fri, 26 Nov 1999, Mike Mascari wrote:
> > Tom Lane <tgl@sss.pgh.pa.us> writes:

> What does ORACLE do here?

> > > Since ORACLE has 70% of the RDBMS market, it is the de facto standard
> > 
> > Yes, and Windows is the de facto standard operating system.  I don't use
> > Windows, and I'm not willing to follow Oracle's lead when they make a
> > bad decision...

> So I guess I should file away my other suggestion to use DCOM as 
> the object technology of choice instead of CORBA? ;-)

This is a Free Software project -- PostgreSQL is not bound by the decisions of
the 'market leader' any more than Linux is bound by the standards of Microsoft.

Having said that, at the same time, a run-time option to mimic Oracle's
behavior might be useful to all of those folk who are trying to port Oracle
applications over to PostgreSQL -- particularly if the SQL is compiled in.

However,  someone who is interested in such an option will probably have to
implement it as well, as it certainly appears to not be a priority issue at
this point.

In cases where Oracle diverges from the SQL-92 or SQL3 standards, should we go
'standard' -- or go  'non-standard' -- the choice should be clear.

We are not competing directly against Oracle, AFAICT -- we serve a different
role altogether.

And I say that while I want an Oracle-specific application to run under
PostgreSQL.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Fri, 26 Nov 1999 15:04:20 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions