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