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
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() |