Proposal: template-ify (binary) extensions

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 extension are handled. (Or between binary and non-binary
extensions.)
- Compatibility and co-existence between file-system and
system catalog based extension templates is simplified.
- Independence of extensions from library files shipped by
3rd party extensions (those would only ship a template, not
the extension per se).
- Paves the way to uploading extensions 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 would still require the
(external) binary code for that specific architecture, because we
cannot possibly store binaries for all architectures.
- A bit of a mind shift for how binary extensions work.

Regards

Markus Wanner