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
|
Список | 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 по дате отправления: