Re: Extension Templates S03E11

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Templates S03E11
Date: 2013-12-02 02:54:43
Message-ID: 20131202025443.GT17272@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> To throw another idea out, also based on the premise that it's a
> namespace problem: if a non-superuser creates an extension template,
> then we force a prefix of that user's username. So a superuser can
> create an "base" extension template with no prefix, but if I create an
> extension template it would be called something like "jdavis"."foo". To
> be more consistent, we could have a reserved prefix that's always
> assumed, similar to pg_catalog.

Ugh, no. We have schemas already (which, as we all know, are even in a
'pg_namespace' catalog..), with permissions associated with them to
allow only certain users to create objects in them, etc.

> > I still think about extensions as being a per-database thing, and that
> > the current security policy makes if a per-major-version thing when the
> > extension contains a module (.so).
> >
> > Also, the dynamic_library_path already allows us to make binary
> > extensions a per-database object again, baring incompatibilities that
> > would manifest themselves as run-time errors…
> >
> > So I strongly vote against making the Extension Templates a set of
> > shared catalogs.
>
> I don't have much of an opinion on this point, but I also don't
> understand your point. Can you clarify? What's the use case for
> DB-specific extension templates?

This is one of my major issues with this approach in general- we're
building this very complicated structure for a use-case which doesn't
exist. There isn't actually any need for per-DB extension templates,
except as a way to create an extension that doesn't require sticking
files on the filesystem, but we only have that requirement because it's
what we've defined extensions *to be*, which is why these end up not
really being extensions but another thing entirely.

I'm completely behind the idea of having packages which install
functions/tables/whatever in some schema, can be installed by a regular
user, and even that the DB could provide some help in tracking metadata
(version information, etc) about those packages, but I don't see
building that on top of extensions in this way.

> I generally think of extension templates as universal, in that
> "myExtension version 1.2.3" is exactly the same everywhere, and
> immutable, so why not share it?

The concern, at least as I've understood it from talking to Dimitri, is
that you don't want everyone to see or have available every extension
template which exists; perhaps there is sensetive code, blah, blah.
Another requirement which doesn't really match up with how extensions
exist today.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-12-02 03:14:10 Re: Extension Templates S03E11
Previous Message Jeff Davis 2013-12-02 02:22:30 Re: Extension Templates S03E11