Re: ALTER EXTENSION .. ADD/DROP weirdness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER EXTENSION .. ADD/DROP weirdness
Date
Msg-id 6494.1318272743@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER EXTENSION .. ADD/DROP weirdness  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ALTER EXTENSION .. ADD/DROP weirdness  (Robert Haas <robertmhaas@gmail.com>)
Re: ALTER EXTENSION .. ADD/DROP weirdness  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: COUNT(*) and index-only scans
Next
From: Robert Haas
Date:
Subject: Re: SET variable - Permission issues