On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina <dan...@heroku.com> wrote: > On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers