[postgis-devel] PSC Vote: Drop the minor in the postgis lib files

Paul Ramsey pramsey at cleverelephant.ca
Fri Sep 14 08:48:39 PDT 2018


Any chance we could defer this one for face-to-face at sprint?

P

> On Sep 14, 2018, at 8:43 AM, Regina Obe <lr at pcorp.us> wrote:
> 
> As mentioned before, though I forget if I got enough consensus to move
> forward.
> 
> I would like the minor of our lib file dropped in 3.0
> 
> So that would mean 
> 
> 1) The installed lib file would be called  postgis-3 for 3.0, 3.1, 3.2  etc.
> rtpostgis-3, postgis_topology-3 etc.
> 2) The extension version would still contain the minor and micro as it
> always has
> 3) We would have a special switch in the .configure (by default turned off),
> for development purposes called:
> 
> --add-lib-minor  (that's my current favorite, though I'm open to changing
> the name)
> 
> This is mostly a development switch so developers can test say 3.0, 3.1 in
> the same postgres instance (different databases) or for those folks who want
> to run both and compile their own postgis.
> 
> 
> -- What this solves
> 
> 1) Much smoother pg_upgrade for users.  Right now whenever anyone needs to
> use pg_upgrade, they need to install  an older postgis in their newer
> install or use a hack to symlink the old name to the new name
> 2) By dropping the Minor, this pain goes away, and also means we don't need
> to always support newer versions of PostgreSQL on older versions of PostGIS
> as long as we release before the PostgreSQL version.
> 
> 
> -- What we give up
> 1) We need to be very careful not to remove C functions exposed in SQL
> scripts that are referenced in older versions of the same major.  So that
> means 3.1 can't remove any C - SQL API exposed functions we introduced in
> 3.0, though it can add more.
>  If we need remove said functions, we need to stub those functions with an
> error code but keep the signature.
> 
> The reason why this is necessary is that during pg_upgrade, the upgrade
> script recreates the extension from what was already installed by installing
> each function, so if during install, it hits a function that can't find it's
> C-function mate, upgrade will fail.
> 
> Note helper functions we have that just get called internally by our other
> functions we can rename all we like.
> 
> 
> +1 to push forward (after all the bots are happy again).
> 
> 
> 
> Thanks,
> Regina
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list