Re: GiST support for inet datatypes
От | Florian Pflug |
---|---|
Тема | Re: GiST support for inet datatypes |
Дата | |
Msg-id | 85B75D9F-CC17-41FC-B9FE-FC2237ABF16A@phlo.org обсуждение исходный текст |
Ответ на | Re: GiST support for inet datatypes (Emre Hasegeli <emre@hasegeli.com>) |
Ответы |
Re: GiST support for inet datatypes
|
Список | pgsql-hackers |
On Feb28, 2014, at 15:45 , Emre Hasegeli <emre@hasegeli.com> wrote: > The problem is that pg_dump --binary-upgrade dumps objects in the extension > on the old cluster, not just the CREATE EXTENSION statement. pg_upgrade > fails to restore them, if the new operator class already exists on the new > cluster as the default. It effects all users who use the extension, even > if they are not using the inet and cidr operator classes in it. Hm, what if we put the new opclass into an extension of its own, say inet_gist, instead of into core? Couldn't we then remove the inet support from the latest version of btree_gist (the one we'd ship with 9.4)? People who don't use the old inet opclass could then simply upgrade the extension after running pg_upgrade to get rid of the old, broken version. People who *do* use the old inet opclass would need to drop their indices before doing that, then install the extension inet_gist, and finally re-create their indices. People who do nothing would continue to use the old inet opclass. inet_gist's SQL script could check whether btree_gist has been upgrade, and if not fail with an error like "btree_gist must be upgraded to at least version x.y before inet_gist can be installed". That would avoid failing with a rather cryptic error later. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: