* Jeff Davis (pgsql@j-davis.com) wrote:
> To make much more progress, it seems like we either need an ingenious
> idea about how to change existing extensions to work for all purposes,
> or we need to invent a new concept.
I'm still in favor of supporting SQL/trusted-language only
'extensions' and allowing them to be installed via a client by a
non-superuser, with perhaps superusers having the ability to install
extensions which use interpreted but untrusted languages.
> As I pointed out before, many language communities handle libraries
> outside of the OS packaging system, e.g. cpan, gems, cabal, pear, etc.
Sure, and we have PGXN, which I believe fits quite a bit better into the
above list than "extension templates". Even so, we could look to try
and add in binary distribution capabilities to PGXN, though David seems
more interested in having a way to go from PGXN source to RPM or Debian
packages. Note also that all of the above operate by downloading
something remote and then installing it *locally*- yet we're being asked
to build a system "like" that which allows installing to a remote system
through a database protocol.
> And you are completely ignoring the common case where people are just
> using C because *postgres says they have to*. For instance, defining new
> data types, implementing the GiST/GIN/SP-GiST APIs, or using some C hook
> in the backend. Those may have no external dependencies at all.
I don't intend to ignore that case- my earlier point was merely that
there seems to be a pretty close split between no C, C with external
dependencies, and C without external dependencies. Based on what I saw
in PGXN, we've got a good bit of all three. The only thing which has
even been proposed thus far to address all three cases is PGXN-
extension templates don't, nor do 'packages' or whatever we want to call
extensions without C code.
Thanks,
Stephen