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

Wed Sep 6 10:24:58 PDT 2017

As for pgRouting,
Version 2.x is being used to do a full rewrite of code that
- was not using any standard
  - at the C/C++ level (development level)
  - at the posgresSQL level (user level)
- was duplicated
- was buggy  (duplicated bugs)

To us, I feel convenient to have the different minor version on the .so at
least during our transition to version 3.

Vicky

On Wed, Sep 6, 2017 at 12:05 PM, Darafei "Komяpa" Praliaskouski <
me at komzpa.net> wrote:

> 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
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>

-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170906/278e13b9/attachment.html>