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 по дате отправления: