Hi,
let me elaborate on an idea I had to streamline extension templates. As
I wrote in my recent review [1], I didn't have the mental model of a
template in mind for extensions, so far.
However, writing the review, I came to think of it. I certainly agree
that extensions which do not carry a binary executable can be considered
templates. The SQL scripts can be deleted after creation of the
extension in the database, because the objects created with them are an
instantiation in the database itself. They do not depend on the template.
That's not the case for compiled, executable code that usually lives in
a shared library on the filesystem. There, the "instantiation" of the
"template" merely consists of a link to the library on the file-system.
If you remove that file, you break the extension.
One way to resolve that - and that seems to be the direction Dimitri's
patch is going - is to make the extension depend on its template. (And
thereby breaking the mental model of a template, IMO. In the spirit of
that mental model, one could argue that code for stored procedures
shouldn't be duplicated, but instead just reference its ancestor.)
The other possible resolution is to make all extensions fit the template
model, i.e. make extensions independent of their templates.
This obviously requires Postgres to internalize the compiled binary code
of the library upon instantiation. (Storing the binary blobs by hash in
a shared catalog could easily prevent unwanted duplication between
databases.)
Advantages:- Consistent mental model: template- Closes the gap between how SQL scripts and binary parts of an
extensionare handled. (Or between binary and non-binary extensions.)- Compatibility and co-existence between
file-systemand system catalog based extension templates is simplified.- Independence of extensions from library files
shippedby 3rd party extensions (those would only ship a template, not the extension per se).- Paves the way to
uploadingextensions that carry a binary, executable payload via libpq.
Challenges:- CPU Architecture must be taken into account for backups. Restoring a backup on a different architecture
wouldstill require the (external) binary code for that specific architecture, because we cannot possibly store
binariesfor all architectures.- A bit of a mind shift for how binary extensions work.
Regards
Markus Wanner