Paul Jungwirth <pj@illuminatedcomputing.com> writes:
> I've got an extension that supplies functions written in C. Two
> databases from the same cluster both use this extension. I understand
> how I can load the example--2.0.0.sql file in one database, and
> example--3.0.0.sql in another, but from what I can tell both databases
> still share the same .so file. Is there any way to provide a separate
> .so for each version?
Not very easily. You can probably make it happen if you're stubborn
enough, but you'd have to do something like having the version update
script CREATE OR REPLACE every last C function in the extension to
change its shlib name from, eg, 'example-2' to 'example-3'.
Another thing that you should think long and hard on is that if you
go this route, there are likely to be scenarios where both libraries
are loaded into a backend process' address space. Will they cope?
(For instance, if they both hook into some backend function hook,
will it be OK that hook actions get done twice?)
I think there are some other gotchas related to getting through a
pg_update scenario. For instance, to get from 9.6 running example-2
to 10 running example-3, you'd need a version of example-2 built for
v10 (if you do the ALTER EXTENSION UPDATE after pg_upgrade) or a
version of example-3 built for 9.6 (if you do it in the other order).
So this definitely isn't going to reduce the number of builds you
have to maintain, rather the opposite.
There was a thread not too long ago concerning somebody who was putting
version numbers in his shlib name, and it was breaking things, and the
general recommendation was "so don't do that". I don't recall the details
but you'd be well advised to check the archives before going that route.
> If not, what is the best approach for releasing a new .so that keeps the
> old functionality? I guess something this?:
> # example--2.0.0.sql
> CREATE OR REPLACE FUNCTION
> myfunc(anyarray)
> RETURNS integer
> AS 'example', 'myfunc_v2_0_0'
> LANGUAGE c IMMUTABLE;
> # example--3.0.0.sql
> CREATE OR REPLACE FUNCTION
> myfunc(anyarray)
> RETURNS integer
> AS 'example', 'myfunc_v3_0_0'
> LANGUAGE c IMMUTABLE;
Yeah, there are several examples of that sort of thing in the contrib
modules. Usually we only stick a version number into the C function
name when the function actually changes meaningfully; otherwise you'll
have a lot of makework boiler-plate in your version update scripts.
(Cases where you really need to do this should be the minority,
I'd think, otherwise you're talking about enough SQL behavioral change
that your users will probably be unhappy with you.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
