Re: pg_dump(all) library

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: pg_dump(all) library
Дата
Msg-id 488B57DE.1020701@commandprompt.com
обсуждение исходный текст
Ответ на Re: pg_dump(all) library  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pg_dump(all) library  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Stephen Frost wrote:
> * David Fetter (david@fetter.org) wrote:
>> This subject keeps coming up, then back down, etc.

> That also got me to thinking about the "pgscript" type of idea, and
> about wildcards for commands, and being able to loop through objects in
> a scriptable way that's not a really ugly combination of psql calls and
> shell script...
> 
> Dunno if that helps much, just trying to get out what was going through
> my head.

It seems to be that quite a bit of pg_dumps functionality could be 
pushed into PostgreSQL as functions. This would end up defining an API 
on its own.

pg_dump the executable would just be a shell that calls the functions in 
appropriate order. This would also assist in the removal of the should 
be defunct years ago pg_dumpall because pg_dump -A would just connect to 
database in sequence (or, all at once if we like using multiple 
connections).

Consider:

pg_dump_schema(ARRAY,TEXT,TEXT)

SELECT pg_dump_schema('{public,foobar}','BINARY','/tmp/foo.sql');

pg_dump_data(ARRAY,TEXT,TEXT)

SELECT pg_dump_data('{public.foo,foobar.baz}','BINARY','/tmp/mydata.sql');

pg_dump_types
pg_dump_tables - only dumps table structures no indexes or constraints
pg_dump_primary_keys
pg_dump_indexes
pg_dump_constraints

etc...

There could be a problem with the whole use the new pg_dump to dump the 
old database.

Sincerely,

Joshua D. Drake







> 
>     Thanks,
> 
>         Stephen



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump(all) library
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Executor question