Chapman Flack <c...@anastigmatix.net> writes:
> I've been looking a little more deeply at the extension mechanism,
> trying to answer my own question about what happens once there have
> 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.
I agree that MODULE_PATHNAME isn't an adequate mechanism if you want
to have version numbers in the .so filenames. We could think about
providing some solution for that, perhaps along the lines of a %v
escape such as you suggest, but it would take awhile for that to get
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
