Re: Inline Extension
От | Robert Haas |
---|---|
Тема | Re: Inline Extension |
Дата | |
Msg-id | CA+TgmobSTh1xb+Dt3asSkKvsrAbynC2DP0oKw79VRE_2ToYbPg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inline Extension (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Inline Extension
|
Список | pgsql-hackers |
On Mon, Jan 23, 2012 at 10:26 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right, >> because the files in the directory correspond to *available* >> extensions, not already-created ones. We need some way of dumping and > > I would have limited the dump query to only known installed extensions, > right. The update scripts are still needed because with inline > extensions you typically never see a 1.2 script but a 1.0 then 1.0--1.1 > and then a 1.1--1.2. Hmm, I don't think I like that design. I think we should view this as a way to embed the SQL and control files needed by the extension in the server, rather than a separate thing called an inline extension. If pg_dump is going to dump those files, it ought to dump them all, not just some subset of them. >> restoring the files themselves, not the extension that can be created >> from them. I suspect internal functions (pg_whatever) make more sense >> than new SQL syntax, since this is really only to make pg_dump happy. > > That could well be, yes, but what would this function do that the > commands are not doing? I'm ok not to invent specific syntax to solve > that problem, I just think that we should already have all we need :) I was thinking of something like pg_write_extension_file('foobar.control', '....content goes here....'); >>> Or do you still want to insist that dump/restore shouldn't care about >>> any extension, inline or not, and so you're given the responsibility to >>> do the exact same thing yourself on the client side? >> >> How about adding a new pg_dump option to suppress this part of the dump? > > Makes sense, indeed. Well one could of course manually filter the dump > object list too, of course… True. I guess that's another reason why a global flag to shut it all off is probably sufficient, but I'm still in favor of having at least that much. I think the average user is much more likely to find pg_dump --skip-whatever than they are to understand how to do dump object filtering correctly, and even the advanced user may appreciate the shortcut on occasion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: