[pgrouting-dev] Backwards Compat

Mon Jun 21 11:13:48 PDT 2021

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
---------+-----------------
3.1.0   | pgrouting-3.2.0
(1 row)

So a bug fix on the C/C++ will be catched, but if there was a bug fix on
3.2 in the SQL, they would be running without that fix until UPDATE
EXTENSION is used.

If the database was created before 3.2.0 was installed, UPDATE EXTENSION is
needed to catch bug fixes in both C & C++

I haven't tried to have a DB, created with, for example, 3.1.0 before 3.2.0
installed, dump the db, install 3.2.0 create a new DB with pgRouting 3.1.0
(using 3.2.0 library) and restore the DB.

So because of that we take special care on keeping the C connection,
https://github.com/pgRouting/pgrouting/blob/develop/src/dijkstra/dijkstra.c#L253
https://github.com/pgRouting/pgrouting/blob/develop/sql/dijkstra/_dijkstra.sql

Things will be cleaned up on version 4.0.0 (whenever that happens.

I hope this help
Regards
Vicky

Example hack:

---------------------------------------------
-- Updating from version 2.6
---------------------------------------------
ALTER EXTENSION pgrouting DROP TYPE pgr_costresult;  DROP TYPE
pgr_costresult CASCADE;
ALTER EXTENSION pgrouting DROP TYPE pgr_costresult3; DROP TYPE
pgr_costresult3 CASCADE;
ALTER EXTENSION pgrouting DROP TYPE pgr_geomresult;  DROP TYPE
pgr_geomresult CASCADE;

UPDATE pg_proc SET
proargnames = '{"","","",directed,seq,path_seq,node,edge,cost,agg_cost}'
WHERE proname = 'pgr_dijkstra'
AND proargnames = '
{edges_sql,start_vid,end_vid,directed,seq,path_seq,node,edge,cost,agg_cost}'
;

On Fri, Jun 11, 2021 at 9:58 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
>
> > On Jun 10, 2021, at 1:47 PM, Regina Obe <lr at pcorp.us> wrote:
> >
> >> 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 at 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 at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>

-- 

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/pgrouting-dev/attachments/20210621/8c78b962/attachment-0001.html>