On Sat, 2011-07-30 at 22:46 +0200, Dimitri Fontaine wrote: > Tom Lane <tgl@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
