On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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
extension-type-dependencies.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
