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

Wed Sep 6 10:05:15 PDT 2017

I've looked at my /usr/lib/postgresql/10/lib/ directory and it seems
postgis and pgrouting are the only libraries that attempt to have version
in their name.

Any reason not to call the library postgis.so, not even postgis-2.so, and
keep symbols from as far as current supported upgrade path allows?

ср, 6 сент. 2017 г. в 19:00, Regina Obe <lr at pcorp.us>:

> I want to itemize my key points
>
> 1) If we did not try to support PostgreSQL versions that couldn't fully
> support the key features of a PostGIS version, we wouldn't have such a mess
> with half-broken pg_upgrade installs.
> That means we should never have supported anything lower than 2.2 in
> PostgreSQL 9.5 and not supported anything lower than 9.5 in 2.3 (the
> parallel stuff since we didn't do much with marking aggs as parallel safe
> in 9.5 ), it was okay to support 9.5 in 2.3.  2.4 should really not be
> supporting anything other than 9.6 and 10. I know it sound draconian but I
> really think it's the best for the majority of people.
>
> If we feel really badly about supporting older versions then we've got to
> put a lot more work into it to prevent half-broken installs.
>
>
> 2) If we just called our library  postgis-2 instead of postgis-2.5 or
> whatever, then
>
> All users will be coming from a lower postgis -- e.g. postgis-2.4.0 or
> postgis-2.3  etc.
> We can provide a clean path for folks coming from lower versions because
> ALTER EXTENSION can recognize something needs to be done
> For pg_upgrade  we can creating a symlink from older versions to postgis-2
> and putting in all our dirty cleanup laundry in postgis-2.5 scripts to
> correct our past sins.
>
> 3) Moving forward don't try to let old versions pass just because they
> can't support a key feature of our new version.
> Don't try to support newer versions of PostgreSQL with old code.  It makes
> us look like liars when people read the "Aha you can do this now
> literature" and they can't.
>
> If our postgis library file was just called postgis-2   then we are free
> to do drop PostgreSQL versions as we see fit andnot impact anyone's upgrade
> path or screw up their install in a hard to fix way.
>
> Thanks,
> Regina
>
>
>
>
>
>
> -----Original Message-----
> From: Regina Obe [mailto:lr at pcorp.us]
> Sent: Wednesday, September 06, 2017 11:34 AM
> To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
> Subject: RE: [postgis-devel] PSC Vote: Change PostGIS library name to drop
> the minor
>
>
> >> It would also solve the issue we have that PostgreSQL 9.4 2.4 upgrading
> to PostgreSQL 9.6 2.4 is missing all the good stuff like true KNN and some
> parallel safe stuff we put in.
>
> > No, this is untrue. The KNN and parallel stuff requires *scripts*
> rebuild and reload, so has nothign to do with the library/module.
>
> > --strk;
>
> I beg to differ again.
>
> If a user has PostgreSQL 9.4 2.4 installed and they migrate to PostgreSQL
> 9.6 2.4
>
> When they go to do
>
> ALTER EXTENSION postgis UPDATE;
>
> Nothing would happen.  It would say they are already current.  Even your
> favorite old-fashioned we have in place will not catch that.
>
>
> However if they were coming from say
>
> PostgreSQL 9.4 2.1  before we introduced all this KNN stuff and Parallel
> stuff that 9.4 can't use anyway -- but we let it pass (oh you can't support
> that lets not give you that).
>
> ALTER EXTENSION postgis UPDATE;
>
> Would run the bits we said you need to run to move from 2.1 to 2.4  which
> would be adding in the KNN logic, dropping and recreating aggs that need to
> be.
>
> Sure you can argue we can add that in the future, but there is no way when
> we call a script 2.4.0 that ALTER EXTENSION postgis UPDATE would try to do
> anything.
>
>
> Sure we could add another function and instruct users.
>
> Oh and if ALTER EXTENSION postgis UPDATE says you need to do nothing,
> don't believe it.
>
> Run
>
> SELECT postgis_full_version();
>
> Make sense of our gobbly gook
>
>
> If you see a message that something to the effect yaddda yadda yadda, then
> run this
>
> .sql script  which will update the function to update your code.
>
> And then you are good.
>
>
> How much freaking stuff do you expect people to do.
> People are already struggling to type the words:
>
>
> ALTER EXTENSION postgis UPDATE;
>
>
> It's hard for both us and them.  Us to try to account for all the
> different versions of PostgreSQL you could have upgraded from and hard for
> them to make sense of what you are asking them to do.
>
> You know how freaking hard it is to explain to users in training.  Oh that
> KNN stuff we talked about that is new in PostGIS 2.2., well forget about it
> if you are running PostgreSQL 9.4 or lower.
>
> And if you hmm upgraded in the past some time using pg_ugrade, you don't
> get it either.  You need to fuck with your install or do a pg_dump /
> pg_restore.
>
>
> Thanks,
> Regina
>
> _______________________________________________
> 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/20170906/fecc256b/attachment.html>