* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > # Why do we want extensions to manage PL user code?
Having a management system for sets of objects is a *great* idea- and one which we already have through schemas. What we don't have is any kind of versioning system built-in or other metadata about it, nor do we have good tooling which leverages such a versioning or similar system. Extensions provide some of that metadata around schemas and object definitions, but they are also currently defined to be built from SQL scripts on the filesystem in a specific way and can "include" shared libraries (though the PG extension, which is in the catalog, doesn't really include the shared libraries, when you think about it...). > # Extension Templates and Binary Modules > > Then as soon as we are able to CREATE EXTENSION mystuff; without ever > pre-installing files on the file system as root, then we would like to > be able to do just that even with binary modules. I really just don't see this as being either particularly useful nor feasible within a reasonable amount of effort. Shared libraries are really the perview of the OS packaging system. If you want to build some tool which is external to PG but helps facilitate the building and installing of shared libraries, but doesn't use the OS packaging system (and, instead, attempts to duplicate it) then go for it, but don't expect to ship or install that through the PG backend. > # Extension Templates and Superusers > > The problem found here is that if a non privileged user installs an > extension template named “pgcyrpto” then the superuser installs what he > believes is the extension “pgcrypto”, the malicious unprivileged user > now is running his own code (extension install script) as a superuser. For my part, the problem here is this notion of extension templates in the PG catalog and this is just one symptom of how that's really not a good approach. Thanks, Stephen
Description: Digital signature