Hi all!
What kind of care do you take to ensure that library symbols don't change over time? So that the library symbols in pgrouting30 match up to pgrouting31 ? I ask because having non-changing names makes upgrade/install/failovers simpler.
P.
Hi all!
What kind of care do you take to ensure that library symbols don't change
over
time? So that the library symbols in pgrouting30 match up to pgrouting31 ?
I ask
because having non-changing names makes upgrade/install/failovers simpler.
P.
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
[Regina Obe]
In prior releases I think symlinking did work fine but there is a lot going
on with pgRouting 3.2 that that might not be the case. I haven't tried
doing that recently.
FWIW it's much less of an issue with pgRouting than it is with PostGIS
because pgRouting is not tied to any data.
So even if pg_upgrade fails, you can just drop the extension and install it
after the upgrade.
Vicky can correct me if I misspoke but I don't think she's that concerned
about it right now, but I don't think C++ functions bound via SQL api don't
change that often. Mostly just additions.
I did mention about keeping the .so name the same as part of this maintain
and that those should go hand in hand with keeping symbols the same.
Otherwise it's still a symlinking pain that few people would understand how
to do. DROP EXTENSION / CREATE EXTENSION after pg upgrade would still be
easier for most unless the .so name doesn't change.
Thanks,
Regina
On Jun 10, 2021, at 1:47 PM, Regina Obe <lr@pcorp.us> wrote:
Hi all!
What kind of care do you take to ensure that library symbols don't changeover
time? So that the library symbols in pgrouting30 match up to pgrouting31 ?
I ask
because having non-changing names makes upgrade/install/failovers simpler.
P.
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev[Regina Obe]
In prior releases I think symlinking did work fine but there is a lot going
on with pgRouting 3.2 that that might not be the case. I haven't tried
doing that recently.FWIW it's much less of an issue with pgRouting than it is with PostGIS
because pgRouting is not tied to any data.
So even if pg_upgrade fails, you can just drop the extension and install it
after the upgrade.
This is what I'm mostly thinking as well... things like backup and restore and replication are less fraught when data types are not involved.
Vicky can correct me if I misspoke but I don't think she's that concerned
about it right now, but I don't think C++ functions bound via SQL api don't
change that often. Mostly just additions.I did mention about keeping the .so name the same as part of this maintain
and that those should go hand in hand with keeping symbols the same.
Otherwise it's still a symlinking pain that few people would understand how
to do. DROP EXTENSION / CREATE EXTENSION after pg upgrade would still be
easier for most unless the .so name doesn't change.Thanks,
Regina_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Hi Paul:
We have many directory/files for the SQL so it’s easier to manage what changed and what did not changed in a PR:
https://github.com/pgRouting/pgrouting/tree/develop/sql
And we have some rules:
Starting from version 3.0.0, we do not change signatures within the same minor.
Only new signatures are allowed on a bigger minor (This is enforced for users facing function, anything can happen for functions starting with underscore.
We have an action that test these requirements:
https://github.com/pgRouting/pgrouting/blob/develop/.github/workflows/check-files.yml#L8
https://github.com/pgRouting/pgrouting/blob/develop/tools/scripts/test_signatures.sh
There are a couple of scripts that are used to build the extension file and the updates files:
https://github.com/pgRouting/pgrouting/tree/develop/sql/scripts
We have indications of when the function was added, (I think) that are used on the script:
https://github.com/pgRouting/pgrouting/blob/develop/sql/bdDijkstra/bdDijkstra.sql#L34
https://github.com/pgRouting/pgrouting/blob/develop/sql/coloring/bipartite.sql#L33
CREATE FUNCTION …
will be converted to
CREATE OR UPDATE FUNCTION …
on an update file if the signature exists on the previous version, or remain as CREATE if it is a new function
some time it fails so there are some hacks when needed and those are special cases: (basically if everything is done correctly the hacks won’t be needed, but unfortunately is not the case yet)
There are hacks for 3.0 and 2.6
https://github.com/pgRouting/pgrouting/blob/develop/sql/scripts/build-extension-update-files.pl#L361
https://github.com/pgRouting/pgrouting/blob/develop/sql/scripts/build-extension-update-files.pl#L396
We use MODULE_PATHNAME
https://github.com/pgRouting/pgrouting/blob/develop/sql/dijkstra/_dijkstra.sql#L57
after installing 3.2.0, doing a:
CREATE EXTENSION pgrouting with version ‘3.1.0’ CASCADE;
will create a database with 3.1.0 SQL code but will use 3.2 library that comes from 3.2.0
SELECT version, library FROM pgr_full_version();
version | library
···
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](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