[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