Re: Extensions and 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions and 9.2
Date: 2012-01-07 03:06:49
Message-ID: CA+TgmoZ72io0qY0u21BScoNHpq_F7VaD7R6Gikx4Pa7dspOPMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-01-07 07:47:12 broken link to PostgreSQL 9.1 repository for Fedora 14
Previous Message Robert Haas 2012-01-07 02:43:18 Re: [v9.2] Fix Leaky View Problem