<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As for pgRouting,<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Version 2.x is being used to do a full rewrite of code that<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- was not using any standard<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> - at the C/C++ level (development level)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> - at the posgresSQL level (user level)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- was duplicated<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- was buggy (duplicated bugs)<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To us, I feel convenient to have the different minor version on the .so at least during our transition to version 3.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Vicky<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 6, 2017 at 12:05 PM, Darafei "Komяpa" Praliaskouski <span dir="ltr"><<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br><br>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?</div><br><div class="gmail_quote"><div dir="ltr">ср, 6 сент. 2017 г. в 19:00, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>>:<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I want to itemize my key points<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
<br>
2) If we just called our library postgis-2 instead of postgis-2.5 or whatever, then<br>
<br>
All users will be coming from a lower postgis -- e.g. postgis-2.4.0 or postgis-2.3 etc.<br>
We can provide a clean path for folks coming from lower versions because ALTER EXTENSION can recognize something needs to be done<br>
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.<br>
<br>
3) Moving forward don't try to let old versions pass just because they can't support a key feature of our new version.<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Regina<br>
<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Regina Obe [mailto:<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>]<br>
Sent: Wednesday, September 06, 2017 11:34 AM<br>
To: 'PostGIS Development Discussion' <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><wbr>><br>
Subject: RE: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor<br>
<br>
<br>
>> 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.<br>
<br>
> No, this is untrue. The KNN and parallel stuff requires *scripts* rebuild and reload, so has nothign to do with the library/module.<br>
<br>
> --strk;<br>
<br>
I beg to differ again.<br>
<br>
If a user has PostgreSQL 9.4 2.4 installed and they migrate to PostgreSQL 9.6 2.4<br>
<br>
When they go to do<br>
<br>
ALTER EXTENSION postgis UPDATE;<br>
<br>
Nothing would happen. It would say they are already current. Even your favorite old-fashioned we have in place will not catch that.<br>
<br>
<br>
However if they were coming from say<br>
<br>
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).<br>
<br>
ALTER EXTENSION postgis UPDATE;<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Sure we could add another function and instruct users.<br>
<br>
Oh and if ALTER EXTENSION postgis UPDATE says you need to do nothing, don't believe it.<br>
<br>
Run<br>
<br>
SELECT postgis_full_version();<br>
<br>
Make sense of our gobbly gook<br>
<br>
<br>
If you see a message that something to the effect yaddda yadda yadda, then run this<br>
<br>
.sql script which will update the function to update your code.<br>
<br>
And then you are good.<br>
<br>
<br>
How much freaking stuff do you expect people to do.<br>
People are already struggling to type the words:<br>
<br>
<br>
ALTER EXTENSION postgis UPDATE;<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Thanks,<br>
Regina<br>
<br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></blockquote></div></div></div>
<br>______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>