Re: [HACKERS] DROP TABLE inside transaction block

From: Leon <leon(at)udmnet(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROP TABLE inside transaction block
Date: 1999-09-06 11:51:46
Message-ID: 37D3AAD2.C0AA4D4A@udmnet.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>
> > Cant you just rename to a unique name, maybee in another directory,
>
> Not if other backends are also accessing the table. Remember that to
> make this really work, the DROP would have to be invisible to other
> backends until commit.
>

Is that really needed? Remember that table's creation is not transparent
to other users - when someone attempts to create a table, others,
though can't see that table, cannot create a table with the same name.
So you can simply issue a draconian-level lock on a table being deleted.
But in any case it would need postponing real killing until transaction
commit.

> The amount of work needed seems vastly more than the feature is worth...

I personally have a project in development which extensively uses
that feature. It is meant to be database restructuring 'on the fly'.
If you break that, it would be a big drawback to me. And I assume, not
only to me, because it would break an idea of trasaction itself.
Database restructuring by software, not by hand, will be seriously
damaged.

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-06 14:12:42 Re: [HACKERS] md.c is feeling much better now, thank you
Previous Message Yu Cao 1999-09-06 06:55:56 Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5