From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER EXTENSION .. ADD/DROP weirdness |
Date: | 2011-10-12 21:04:37 |
Message-ID: | CA+TgmoZ6eb4nj5r=Xko9p+SBeubz5smf+AcejxZ+YGr_WrS-yA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> But there's a bigger problem: it seems to me that we have an
>> inconsistency between what happens when you create an extension from
>> scratch and when you upgrade it from unpackaged. Both pg_buffercache
>> and pg_stat_statements just do this in the "upgrade from unpackaged"
>> case:
>
>> ALTER EXTENSION <ext-name> ADD view <view-name>;
>
>> They do *not* add the type and the array type. But when the "1.0"
>> script is run, the type and array type end up belonging to the
>> extension. This seems bad.
>
> Hmm, yeah, we need to make those consistent.
>
> 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.
Of course, this won't fix any damage already done, but it seems like
the right thing going forward.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
extension-type-dependencies.patch | application/octet-stream | 807 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2011-10-12 21:07:40 | Re: [BUGS] *.sql contrib files contain unresolvable MODULE_PATHNAME |
Previous Message | Tom Lane | 2011-10-12 21:00:16 | Re: pl/perl example in the doc no longer works in 9.1 |