Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION? |
Дата | |
Msg-id | 23275.1504617738@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION? (Sandro Santilli <strk@kbt.io>) |
Список | pgsql-hackers |
Sandro Santilli <strk@kbt.io> writes: > On Wed, Aug 30, 2017 at 06:01:58PM -0400, Tom Lane wrote: >> 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") ? To be precise, pg_dump when working on behalf of pg_upgrade (that is, with the --binary-upgrade switch). >> 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. FWIW, I do not think that the library file name is a useful place to try to enforce such a thing. Changing the file name creates complications for upgrade, and it doesn't actually stop you from breaking anything. regards, tom lane
В списке pgsql-hackers по дате отправления: