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-10 18:08:23 |
Message-ID: | CA+TgmoYN=7EnO2TFc4ow-X6vT9f6ZZuxKt0YrUmiFxXm9j4_6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 10, 2011 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> rhaas=# alter extension pg_stat_statements drop type pg_stat_statements[];
>> ERROR: syntax error at or near "["
>> LINE 1: ...extension pg_stat_statements drop type pg_stat_statements[];
>> ^
>
>> Hmm. So just how do I do this?
>
> "alter extension pg_stat_statements drop type _pg_stat_statements",
> probably.
*tests*
Yeah, that works. But it seems undesirable for people writing upgrade
scripts to need to count on the way we generate internal type names
for array types.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2011-10-10 18:25:59 | Overhead cost of Serializable Snapshot Isolation |
Previous Message | Thom Brown | 2011-10-10 18:06:16 | Re: Range Types - typo + NULL string constructor |