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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
