Dropping extensions

Marc Munro <marc@bloodnok.com> writes:

In postgres 9.1 I have created 2 extensions, veil and veil_demo. When I
install veil, it creates a default (not very useful) version of a
function: veil_init().

When I create veil_demo, it replaces this version of the function with
it's own (useful) version.

If I drop the extension veil_demo, I am left with the veil_demo version
of veil_init().

Is this a feature or a bug? Is there a work-around?

Hmm. I don't think we have any code in there to prohibit the same
object from being made a member of two different extensions ... but this
example suggests that maybe we had better check that.

In general, though, it is not intended that extension creation scripts
use CREATE OR REPLACE, which I gather you must be doing.

regards, tom lane

On Sat, 2011-07-23 at 11:08 -0400, Tom Lane wrote:

If I drop the extension veil_demo, I am left with the veil_demo version
of veil_init().

Is this a feature or a bug? Is there a work-around?

Hmm. I don't think we have any code in there to prohibit the same
object from being made a member of two different extensions ... but this
example suggests that maybe we had better check that.

In general, though, it is not intended that extension creation scripts
use CREATE OR REPLACE, which I gather you must be doing.

That's right. Ultimately I'd like to be able to create a number of
extensions, all further extending the base functionality of veil, with
each one further extending veil_init(). I could consider a more
generalised callback mechanism but that adds more complexity and
overhead without really buying me anything functionally. I will look
into it though.

While it would be great to be able to return functions to their previous
definition automatically, other simpler mechanisms might suffice. For
me, being able to run a post-drop script would probably be adequate.
For now, I will just add some notes to the documentation.

Thanks for the response.

__
Marc

Tom Lane <tgl@sss.pgh.pa.us> writes:

Hmm. I don't think we have any code in there to prohibit the same
object from being made a member of two different extensions ... but this
example suggests that maybe we had better check that.

I see you did take care of that, thank you!

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=988cccc620dd8c16d77f88ede167b22056176324

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Sat, 2011-07-30 at 22:46 +0200, Dimitri Fontaine wrote:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Hmm. I don't think we have any code in there to prohibit the same
object from being made a member of two different extensions ... but this
example suggests that maybe we had better check that.

I see you did take care of that, thank you!

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=988cccc620dd8c16d77f88ede167b22056176324

I thought I'd document how I fixed Veil's drop extension issue.

The problem is that veil_init() needs to be able to do different things
depending on how Veil has been extended. In the past, we simply
re-wrote veil_init() for the application. Now that we have proper
extensions this is no longer viable.

So, I have modified veil_init() to call functions that have been defined
in a configuration table. An extension can now register its own init
functions by inserting their details into the config table.

This is almost perfect, except that when an extension is dropped, the
inserted records must be deleted.

We achieve this by creating a new config table for each extension, which
inherits from the veil config table. When veil queries its config
table, it sees the inherited tables too, and can find their init
functions. When the extension is dropped, the inherited table is also
dropped and veil_init() reverts to its previous behaviour.

Yay.
__
Marc