Chapman Flack <> 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,

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 (
To make changes to your subscription:

Reply via email to