Re: Extensions and 9.2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Extensions and 9.2
Date
Msg-id CA+TgmoZ72io0qY0u21BScoNHpq_F7VaD7R6Gikx4Pa7dspOPMA@mail.gmail.com
Whole thread Raw
In response to Re: Extensions and 9.2  (Daniel Farina <daniel@heroku.com>)
List pgsql-hackers
On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina <daniel@heroku.com> wrote:
> On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas <robertmhaas@gmail.com> wrote:>
>> Assuming the command in
>> question can be stuffed inside a function, the most you're gaining is
>> a little notational convenience
>
> I can answer that one (why a full-blown mechanism for a notational convenience).
>
> It has occurred to me to use this mechanism to support extensions, but
> I find the prospect of having to teach people special operators to
> understand how to use the standard extension feature an unstomachable
> prospect.  The single biggest problem is that pg_restore will not know
> to call this function rather than run CREATE EXTENSION, and then two
> databases, prepared exactly the same cannot be pg_dump-ed and restored
> in a reasonable way.  If there's a definable whitelist, then this
> vital functionality will work.
>
> There are other sicknesses imposed if one has to hack up how to
> delegate extension creation to non-superusers:
>
> * The postgres manual, wiki, and ecosystem of recipes on the web and
> internet at large basically are not going to work without
> modification.  Death by a thousand cuts.
>
> * "\df" in psql displays some new operators that you aren't familiar
> with.  Also, putting aside your pg_dump/pg_restore generated SQL will
> not work, they will look funny.  This is an eyesore.
>
> * If one tells someone else "yeah, the system supports extensions",
> they're going to type CREATE EXTENSION.  And then it's not going to
> work, and then they're either going to give up, yak shave for a few
> hours figuring out what they were "supposed" to do for their provider
> or organization, or maybe worst of all hack their way around
> functionality the extension could have provided in a cleaner way had
> it just worked nice and tidy to begin with.
>
> I find this functionality basically vital because it greatly decreases
> the friction between people, organizations, and software in the domain
> of deploying, reasoning, and communicating about the installation and
> status of Postgres extensions in a database.

OK, I'll buy that.  I think we need to consider the design of the
mechanism carefully, though, or we'll end up with something messy and
inconvenient.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.2] Fix Leaky View Problem
Next
From: Pavel Stehule
Date:
Subject: broken link to PostgreSQL 9.1 repository for Fedora 14