Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION?
От | Sandro Santilli |
---|---|
Тема | Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION? |
Дата | |
Msg-id | 20170905082223.svelslxz6sy6xiqi@liz обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION?
|
Список | pgsql-hackers |
On Wed, Aug 30, 2017 at 06:01:58PM -0400, Tom Lane wrote: > "Regina Obe" <lr@pcorp.us> writes: > > I think this thread covers most of the issues. > > https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html > > My thought was is it possible for pg_upgrade to be taught to use CREATE > > EXENSION if asked? > > We intentionally *don't* do that; pg_dump goes to a lot of trouble to > duplicate the old extension contents exactly, instead. There are a bunch > of corner cases that would fail if we allowed the new installation to > have different extension contents than the old. Believe you me, we'd > rather have just issued CREATE EXTENSION, but it doesn't work. Did you mean `pg_upgrade` ("goes to a lot of trouble") ? Because I'm pretty sure I saw a `CREATE EXTENSION` in a dump created by pg_dump from PostgreSQL 9.6 > Looking quickly at the thread you cite, I wonder how much of this problem > is caused by including version numbers in the library's .so filename. > Have you considered not doing that? The name change is intentional, to reflect a promise we make between patch-level releases but not between minor-level releases. The promise to keep C function signatures referenced by SQL objects immutable and behavior compatible. --strk;
В списке pgsql-hackers по дате отправления: