Re: Extensions and 9.2
От | Robert Haas |
---|---|
Тема | Re: Extensions and 9.2 |
Дата | |
Msg-id | CA+TgmoZ72io0qY0u21BScoNHpq_F7VaD7R6Gikx4Pa7dspOPMA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extensions and 9.2 (Daniel Farina <daniel@heroku.com>) |
Список | 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 по дате отправления: