Phil Sorber <phil@omniti.com> writes:
> Running Postgres 9.1.3. As far as I can tell, when you do an 'alter
> table' and add a new column with a new default value a temp table is
> created and tracked by the extension as a new object, but when the
> 'alter table' statement tries to drop the temp table at the end, the
> extension complains. I recreated it with a simple test case.
Hm, interesting. ATRewriteTable creates a meant-to-be-transient table
to serve as a holder for the new heap until it's done building that.
However, recordDependencyOnCurrentExtension doesn't know that the table
is meant to be transient and links it to the current extension; so when
the table gets dropped a bit later, the dependency code complains.
More generally, this means that an extension creation or update script
cannot create, use, and drop any sort of transient object, unless it
remembers to explicitly unlink the transient object from the extension
before the DROP.
We could probably kluge something to prevent the table made by
make_new_heap from being entered as an extension dependency, or else do
an explicit removal of the dependency in finish_heap_swap. But I'm
worried that there may be other similar cases, which we'd have to find
piecemeal.
Instead, I'm tempted to propose that dependency.c explicitly allow drops
of objects that belong to the current extension, when an extension is
being created or updated. (That is, if we come across a dependency
reference to the active extension, we just ignore it. A quick look
suggests that this would require only a very small patch.) That would
prevent the entire class of problems.
It would also have the effect that explicit DROPs of member objects in
extension scripts could be done without an explicit ALTER EXTENSION DROP
first. I think we'd originally decided that requiring the ALTER was a
good safety feature, but is it really more than nanny-ism? The intent
of a DROP command seems pretty clear.
Thoughts?
regards, tom lane