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
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 |