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
