* 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
signature.asc
Description: Digital signature
