Re: Extension Templates S03E11 - Mailing list pgsql-hackers

On Mon, Dec 2, 2013 at 10:13 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>> I fear we're wandering off the point again. So let me repeat: It must be
>> possible to install the same extension the way you do today, and using the
>> new mechanism.
>
> The way you do today is running make install or apt-get install or
> something else to write files in the right place on the file system,
> usually with root privileges.
>
> The new mechanism tries to avoid using the file system *completely*.
>
> Sorry. I don't understand what you mean other that “I don't want this
> patch because I don't understand what it is about”.

OK, I'll bite.  I've been trying to stay out of this thread, but I
really *don't* understand what this patch is about.  Extensions, as
they exist today, are installed from the filesystem and their contents
are not dumped.  You're trying to create a new kind of extension which
is installed from the system catalogs (instead of the file system) and
is dumped.  Why should anyone want that?

It seems that part of the answer is that people would like to be able
to install extensions via libpq.  You could almost write a client-side
tool for that today just by using adminpack to write the files to the
server, but you'd trip over the fact that files written by adminpack
must be in either the data directory or the log directory.  But we
could fix that easily enough.  Here's a design sketch: (1) Add a new
GUC that specifies an alternate location from which extensions can be
installed.  (2) Allow adminpack to write to that location just as it
writes to the existing locations.  (3) Write a tool that copies files
from wherever to the appropriate server directory using adminpack.
Problem solved!  The only downside is that the use of this facility
would have to be restricted to superusers, but the current consensus
on this thread is that we should restrict *this* facility to
superusers also, so we're not really losing anything.  And, for a
further plus, it'd even work for extensions that contain shared
libraries.  Win.

Now, if we could make this mechanism work for non-superusers, then I
think it gets more interesting, because now you have a more
significant gain in functionality: someone can potentially download an
extension from PGXN and install it just for themselves without needing
superuser access, provided the extension doesn't require a .so or any
permissions that they don't have.  That's kind of nice, but as Stephen
said elsewhere on the thread, this seems like a lot of mechanism for
that narrow goal.  As you (I think) said somewhere on this thread, you
could just create the extension with a bunch of CREATE and ALTER
EXTENSION .. ADD statements and set a flag on it that causes it to be
dumped the same way.  (We might need to add a CREATE EXTENSION foo
WITH NO CONTENTS statement to really make it work, so that the libpq
connection can create it as completely empty and then add objects to
it one at a time, but we shouldn't need too much more than that.)  The
whole idea of the extension template as such goes away.

So I'm having a hard time understanding what this patch actually gains
us that can't be done more simply by some other means.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company