Re: Extension tracking temp table and causing update failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Phil Sorber <phil(at)omniti(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Extension tracking temp table and causing update failure
Date: 2012-03-07 15:59:09
Message-ID: 8167.1331135949@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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 detach the object from the extension then drop
> it. That makes perfect sense in general but is a useless restriction
> when executing an extension's script.

Actually, on further thought I am not sure we really considered the idea
of a DROP in an extension script at all --- it's not something that you
would normally expect an extension to want to do for an exported object,
and I'm pretty sure none of us thought about transient objects.

But anyway, we all seem to agree that this seems like a reasonable fix,
so I will look into making it happen.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mike Blackwell 2012-03-07 17:22:00 Altering a table with a rowtype column
Previous Message Kevin Grittner 2012-03-07 15:34:11 Re: BUG #6523: Problems with dbpool()