Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
>
> [...]
>
> 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.
Thinking about it, what I think makes sense at the user level is that
you can either DROP an extension's object in the extension script or
detach it so that it still exists on its own.
That means we still need to be able to ALTER EXTENSION =E2=80=A6 DROP and t=
hat
this operation should be automatically handled when the extension's
script contains a DROP command. The way to implement that seems to be
exactly what you're saying.
(So that view is mostly useful for how to document the behaviour).
> 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.
What I remember we decided is that you can't DROP any single object of
an extension alone, you have to drop the extension wholesale or not at
all. So that you first =E2=80=9Cdetach=E2=80=9D the object from the extensi=
on then drop
it. That makes perfect sense in general but is a useless restriction
when executing an extension's script.
I consider that bugfix for back branches, by the way (well, 9.1).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
