Re: ALTER EXTENSION .. ADD/DROP weirdness

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ALTER EXTENSION .. ADD/DROP weirdness
Дата
Msg-id CA+TgmoYN=7EnO2TFc4ow-X6vT9f6ZZuxKt0YrUmiFxXm9j4_6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION .. ADD/DROP weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER EXTENSION .. ADD/DROP weirdness
Список pgsql-hackers
On Mon, Oct 10, 2011 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Range Types - typo + NULL string constructor
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] DROP statement reworks