On 02/16/16 22:44, Tom Lane wrote: > Chapman Flack <c...@anastigmatix.net> writes: >> been several releases of an extension, and the extensions directory >> is now populated with a bunch of files quux--1.0.sql, quux--1.1.sql, >> quux--1.0--1.1.sql, quux--1.1--1.0.sql, ..., quux.control. >> And somewhere in $libdir there are quux-1.0.so, quux-1.1.so. > > Well, at least so far as the existing extensions in contrib are concerned, > there are *not* version numbers in the .so filenames. This means you > can't have more than one version of the .so installed at once, but we've > not really found a need for that. It's usually feasible --- and desirable > --- to keep ABI compatibility to the extent that the new .so can be > swapped in for the old without needing to change the SQL function > definitions immediately.
It's true enough that in PL/Java's case, the ABIs / interfaces between the SQL function definitions and their implementations in the .so have been quite stable for years, so there might be no immediate problem. On the other hand, other details of the implementation (bugs come to mind) do change ... letting a version-specific CREATE EXTENSION load an unversioned .so could lead to surprises in that area, because it would /appear to succeed/, meaning pg_extension.extversion would get changed to what you /thought/ you had loaded (and what you would probably answer, if asked "what version are you reporting this bug against?"), while what's actually running could be different, and if I squint I see diagnostic headaches lying not far around that bend. > into the field. Avoiding MODULE_PATHNAME in favor of writing out > the versioned .so name in the .sql files is probably the path of > least resistance. Agreed ... for once maybe I'll follow it. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
