Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Dropping extensions

From: Marc Munro <marc(at)bloodnok(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [GENERAL] Dropping extensions
Date: 2011-07-23 16:57:26
Message-ID: 1311440246.11645.12.camel@bloodnok.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2011-07-23 17:35:41
Subject: Re: Policy on pulling in code from other projects?
Previous:From: Florian PflugDate: 2011-07-23 16:46:32
Subject: Re: XPATH vs. server_encoding != UTF-8

pgsql-general by date

Next:From: Godofredo ContrerasDate: 2011-07-23 17:17:08
Subject: Re: Question about uuid_generate_v3
Previous:From: Chris TraversDate: 2011-07-23 16:47:03
Subject: Re: Implementing "thick"/"fat" databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group