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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] multiple target of VACUUM command
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] why not parallel seq scan for slow functions