* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> > So, to support uploading PGXN zip files directly within the backend, now
> > the backend must be in a position to unpack the archive and build the
> > extension, then it must know where the build artefacts are going to be
> > found or it needs to `make install` in a known prefix and follow our
> > current conventions to find the files.
>
> As I've said multiple times before, this is an absolute nonstarter.
> It's insane from a security standpoint, and it requires a whole lot
> of infrastructure that wouldn't be there on a production box
> (starting with the Postgres header files, but even a C compiler
> wouldn't necessarily be there).
>
> What you are looking for is a software distribution channel. A postgres
> daemon isn't that and we shouldn't try to make it that.
I tend to agree and I've been trying to hash this out with Dimitri on
IRC this morning. One proposal that I personally like is the notion of
having an external-to-PG client which works with pgxn and simply
installs the various objects into a schema based on some naming schema,
with a table in that schema which handles the control information. This
external utility would handle upgrades by looking at the 'control' table
and then figuring out which script from the pgxn package needs to be
run.
These wouldn't be PG "extensions" really though, which it seems folks
are pretty hung up on. There would also be no support for binary or
untrusted components, which is a bit frustrating, as you'd like to be
able to support those if you're a superuser. Trying to build both into
one "extension template" structure, or what-have-you, seems to be
causing us to fail to make any progress on either use-case.
Thanks,
Stephen