Re: ALTER EXTENSION .. ADD/DROP weirdness

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-10 18:52:23
Message-ID: 6494.1318272743@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:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-10 18:55:27 Re: SET variable - Permission issues
Previous Message Tom Lane 2011-10-10 18:43:07 Re: COUNT(*) and index-only scans