| 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: | Whole Thread | Raw Message | 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.
| 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 |