Re: Inline Extension
От | Dimitri Fontaine |
---|---|
Тема | Re: Inline Extension |
Дата | |
Msg-id | 87ipk2cue9.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: Inline Extension (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Inline Extension
|
Список | pgsql-hackers |
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. > 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 :) >> 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… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: