Re: pg_upgrade changes can it use CREATE EXTENSION?

From: "Regina Obe" <lr(at)pcorp(dot)us>
To: "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'PostGIS Development Discussion'" <postgis-devel(at)lists(dot)osgeo(dot)org>
Subject: Re: pg_upgrade changes can it use CREATE EXTENSION?
Date: 2017-08-31 04:53:57
Message-ID: 000e01d32215$27ea7210$77bf5630$@pcorp.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry for the cross posting on this one, but I think it's important both groups are aware.

>> 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.

> 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.

Most of it is. That's why I proposed at least only bumping on major upgrade. So postgis 2.4 so would be called postgis-2.so instead of postgis-2.4.so

We would only change on disk format during major in which case pg_upgrade wouldn’t work for folks anyway (such as what happened going from PostGIS 1.5 to 2.0)

> Have you considered not doing that? Our experience with maintaining the
> contrib modules is that it's easier to attach a version number to an
> individual function (in its C name, where it's irrelevant to SQL users).
> If you incompatibly upgrade a given function, you can leave a stub behind,
> with the old C symbol, that does nothing but throw an error if called.
> Or you can keep on supporting the old API if it's easy enough; it
> doesn't have to be a library-wide decision.
> Have you considered not doing that? Our experience with maintaining the
> contrib modules is that it's easier to attach a version number to an
> individual function (in its C name, where it's irrelevant to SQL users).
> If you incompatibly upgrade a given function, you can leave a stub behind,
> with the old C symbol, that does nothing but throw an error if called.
> Or you can keep on supporting the old API if it's easy enough; it
> doesn't have to be a library-wide decision.

People were all worked up about breaking ABI and also not being able to run two different versions of PostGIS in same cluster.
We rarely break ABI and if we did, like you said it wouldn't kill us
to keep the old C name around until we did a major upgrade.

So I'm all for that idea. I figure we'll rarely need to do that anyway.

It's mostly PostGIS developers like me that need to run two different versions of PostGIS in same cluster mostly for regression testing.
Which is why I proposed having a configure switch which is by default off.

Here is my original vote request.
https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026319.html

> My solution of let's not call it postgis-2.4 but just postgis-2 from
> thenceforward for the life of 2 major series because we don't break backward
> compatibility often in a PostGIS minor version got shot down.

> The thread you mention doesn't seem to include any arguments why not
> to do that.

> regards, tom lane

Some people had issue with trying to do that at PostGIS 2.4 right after we already released the alpha and are less than a month away from release.
Though technically we haven't released beta yet so I didn't think it was that big of a deal.

But I'm willing to wait for PostGIS 2.5 to appease people.

Tom, as always, thanks for being a voice of reason,

Regina

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jing Wang 2017-08-31 05:38:46 Re: Support to COMMENT ON DATABASE CURRENT_DATABASE
Previous Message Peter Eisentraut 2017-08-31 04:16:43 generated columns