Thread

  1. Re: [HACKERS] DROP TABLE inside transaction block

    Jose Soares <jose@sferacarta.com> — 1999-09-07T12:55:56Z

    
    Tom Lane ha scritto:
    
    > Pursuant to a phone conversation I had with Bruce, I added code this
    > morning to reject DROP TABLE or DROP INDEX inside a transaction block;
    > that is, you can't do BEGIN; DROP TABLE foo; END anymore.  The reason
    > for rejecting this case is that we do the wrong thing if the transaction
    > is later aborted.  Following BEGIN; DROP TABLE foo; ABORT, the system
    > tables will claim that foo is still valid (since the changes to them
    > were never committed) but we've already unlinked foo's physical file,
    > and we can't get it back.  Solution: only allow DROP TABLE outside
    > BEGIN, so that the user can't try to change his mind later.
    >
    > However, on second thought I wonder if this cure is worse than the
    > disease.  Will it be unreasonably hard to drop tables using client
    > interfaces that like to wrap everything in BEGIN/END?  Plugging an
    > obscure hole might not be worth that.
    >
    > A possible compromise is not to error out, but just to issue a NOTICE
    > along the lines of "DROP TABLE is not undoable, so don't even think of
    > trying to abort now..."
    >
    > (Of course, what would be really nice is if it just worked, but I don't
    > see any way to make that happen without major changes.  Simply
    > postponing the unlink to end of transaction isn't workable; consider
    > BEGIN; DROP TABLE foo; CREATE TABLE foo; ...)
    >
    > Any thoughts?  Will there indeed be a problem with JDBC or ODBC if we
    > leave this error check in place?
    >
    >                         regards, tom lane
    >
    > ************
    >
    > ************
    
    Seems a good solution. I have an old note about this problem.
    What about to reject also the following commands inside transactions?
    
    
    * BUGS: There are some commands that doesn't work properly
                   inside transactions. Users should NOT use the following
                  statements inside transactions:
    
         - DROP TABLE      -- in case of ROLLBACK only table structure
                                             will be recovered, data will be
    lost.
         - CREATE VIEWS    -- the behavior of the backend is unpredictable.
         - ALTER TABLE     -- the behavior of the backend is unpredictable.
         - CREATE DATABASE -- in case of ROLLBACK will be removed references
                              from "pg_database" but directory
    $PGDATA/databasename will not be removed.
    
    José