Re: late binding of shared libs for C functions

This thing also bites PostGIS upgrades.

When distro's packaging system decides to upgrade PostGIS, or both
Postgres/PostGIS at the same time, you may often get to a situation when
you only have one version of PostGIS .so installed, and it's not the one
referenced in catalog. There are workarounds that tell you to symlink a
newer PostGIS .so file to the spot an older one is being looked for, and
then do ALTER EXTENSION UPGRADE to get out of this inconsistent state.

This also means PostGIS has to ship stubs for all the functions that should
have been deleted, but may be needed during such hacky upgrade process.
For example,
https://github.com/postgis/postgis/blob/16270b9352e84bc989b9b946d279f16e0de5c2b9/postgis/lwgeom_accum.c#L55

вт, 12 июн. 2018 г. в 13:48, Geoff Winkless <pgsqladmin(at)geoff(dot)dj>:

> Hi All
>
> Is it possible to use CREATE FUNCTION to link a shared library that
> doesn't yet exist? I don't think it is, but I might be missing
> something.
>
> If not, would it be something that people would be open to a patch
> for? I'm thinking of e.g.
>
> CREATE [ OR REPLACE ] FUNCTION
> name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = }
> default_expr ] [, ...] ] )
> [ RETURNS rettype
> | RETURNS TABLE ( column_name column_type [, ...] ) ]
> { LANGUAGE lang_name
> | TRANSFORM { FOR TYPE type_name } [, ... ]
> | WINDOW
> | IMMUTABLE | STABLE | VOLATILE | [ NOT ] LEAKPROOF
> | CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
> | [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
> | PARALLEL { UNSAFE | RESTRICTED | SAFE }
> | COST execution_cost
> | ROWS result_rows
> | SET configuration_parameter { TO value | = value | FROM CURRENT }
> | AS 'definition'
> - | AS 'obj_file', 'link_symbol'
> + | AS 'obj_file', 'link_symbol' [UNBOUNDED]
> } ...
> [ WITH ( attribute [, ...] ) ]
>
>
> (I know UNBOUNDED isn't quite the word - BINDLATE would be better -
> but I figured I should try to use an existing reserved keyword...)
>
> We run our SQL scripts before we install binaries (because our
> binaries are started by the installer, so having the database in place
> is a Good Thing). The binary installer includes the .so. We're now
> stuck in a catch-22 where I can't run the SQL script because it
> requires the .so to be in place, but I can't run the binary installer
> because if I do the SQL won't be updated...
>
> This specific problem is obviously workaround-able, but it occurred to
> me that since the libraries are bound late anyway it seems like this
> wouldn't cause any serious problems.
>
> Of course chances are I've missed something...
>
> Geoff
>
>