[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

[Darafei "Komяpa" Praliaskouski]

Can PostGIS detect version mismatch (the NEED UPGRADE in full_version) and
either perform a self-upgrade on first launch, or fail early with version
mismatch message if it, say, doesn't have permissions?

вт, 5 сент. 2017 г. в 22:53, Paul Ramsey <pramsey at cleverelephant.ca>:

>
> > On Sep 5, 2017, at 10:58 AM, Mark Cave-Ayland <
> mark.cave-ayland at ilande.co.uk> wrote:
> >
> > On 04/09/17 23:08, Regina Obe wrote:
> >
> >> Creating a symlink from postgis-2.4  (compiled for PostgreSQL 10)  and
> calling the link postgis-2.3
> >> is a lot less evil I think.
> >>
> >> In fact your PostGIS will still work after upgrade even if you don't
> rush to do
> >>
> >> ALTER EXTENSION postgis UPDATE;
> >>
> >> Because we did not remove any functions exposed via the SQL scripts.
> We only added functions.
> >>
> >> You can even do this for postgis-2.2 and you'll be fine.
> >>
> >> But as Darafei pointed out in the last comment
> >>
> >>
> >> https://gist.github.com/Komzpa/994d5aaf340067ccec0e
> >>
> >> Many people just don't get that.  It's a hard thing for people to
> fathom.
> >>
> >> That you can take   postigs-2.4 compiled for PostgreSQL 10 and call it
> postgis-2.3 PostgreSQL 10 and it will work.
> >>
> >> BUT
> >>
> >> postgis-2.3 compiled for PostgreSQL 9.6  CAN NOT BE USED by something
> looking for PostgreSQL 10 postgis-2.3
> >> (though they both have 2.3 they are incompatible).
> >>
> >> Thus my need to just ditch the minor to make every one's life easier.
> >
> > Sure, I understand this. But reiterating my point from a previous email,
> > pg_upgrade exists to update any on-disk binary changes and internal
> > APIs. The assumption is that all other external libraries will remain
> > the same, however I'm uncertain exactly what "the same" means in
> > PostgreSQL terms.
> >
> > For example if PostgreSQL 10 makes a binary change to the Datum struct
> > or the AnalyzeStats struct compared to 9.6 then there is nothing we can
> > do about this without a recompile, and I can't see how dropping the
> > minor version would help here. So from what you are saying above, does
> > that mean such a breaking change has taken place between 9.6 and 10?
>
> There’s a core assumption that the versions of postgis and pgsql folks
> would be using would be kept functionally in sync through the mechanism of
> packaging: if you’re upgrading from
>
> postgresql-9.5
> postgresql-9.5-postgis-2.3
>
> to
>
> postgresql-9.6
> postgresql-9.6-postgis-2.4
>
> then you can do a process of
>
> - install new packages (now your install it dead until you)
> - pg_upgrade
> - start up your new instance
> - finally ALTER EXTENSION postgis UPDATE …
>
> in some respects this is also a “magic” upgrade since if you forget the
> finally step your system will still probably work since 99.9% of the old
> functions will still bind to the new postgis.so.
>
> It seems like a “least worst” option given the current state of affairs,
> though I’d rather do it for 3.x than a 2.x. YMMV kind of a thing.
>
> It would be nice if the pgsql extension mechanism had a hook where it
> could ask the extension what it thinks its version is, so that pgsql itself
> could raise the issue “hey, your extension thinks it’s version 3.0, but
> your library is version 3.1, want to fix that?”.
>
> Because the final black box at the end of all this stuff is the fact that
> the “ALTER EXTENSION UPDATE” step seems like extra voodoo: "why do I have
> to do this, I already installed the update via yum/apt-get, right?"
>
> ATB,
> P
>
>
> >
> >
> > ATB,
> >
> > Mark.
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170905/e31ac7c7/attachment.html>