[pgrouting-dev] Backwards Compat

[Paul Ramsey]

> 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