From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER EXTENSION .. ADD/DROP weirdness |
Date: | 2011-10-12 21:15:50 |
Message-ID: | 29788.1318454150@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The underlying issue here is whether objects dependent on an extension
>> member should have direct dependencies on the extension too, and if not,
>> how do we prevent that? The recordDependencyOnCurrentExtension calls
>> don't have enough information to know what to do, I think.
> After looking at this code, it seems that we've generally made that
> the caller's problem - e.g. in heap_create_with_catalog(), we skip
> recordDependencyOnCurrentExtension() if we're dealing with a composite
> type. So I think the fix here is just to move the
> recordDependencyOnCurrentExtension() call in pg_type.c inside the
> if-block that precedes it, as in the attached patch.
Hmm. I'm afraid that's going to break something, because I had had it
like that originally and changed it in commit
988cccc620dd8c16d77f88ede167b22056176324. However, I'm not quite sure
*what* it will break, because it seems like in general extension
dependencies ought to act pretty nearly like owner dependencies.
In a quick look, this seems to be the only place where we're doing it
differently (without a clear reason) for recordDependencyOnOwner and
recordDependencyOnCurrentExtension.
Let me poke at it a bit more. The proposed patch is a bit short on
comment fixes, anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-10-12 21:22:59 | Re: Overhead cost of Serializable Snapshot Isolation |
Previous Message | Josh Berkus | 2011-10-12 21:11:52 | Re: Dumping roles improvements? |