On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.
Well, I'm not an expert on this code, but from a user perspective, I
think it would be nicer if only the view ended up being a member of
the extension, and the generated types did not. Otherwise, writing an
extension upgrade script requires detailed knowledge of what other
objects are going to be generated internally. In fact, it doesn't
seem implausible that the set of internally generated objects from a
given DDL command could change between releases, which would really be
rather ugly here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
