From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sandro Santilli <strk(at)kbt(dot)io> |
Cc: | Regina Obe <lr(at)pcorp(dot)us>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade changes can it use CREATE EXTENSION? |
Date: | 2017-09-05 13:22:18 |
Message-ID: | 23275.1504617738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sandro Santilli <strk(at)kbt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2017-09-05 13:47:06 | Re: Proposal for changes to recovery.conf API |
Previous Message | Vladimir Borodin | 2017-09-05 13:20:02 | Re: Proposal: pg_rewind to skip config files |