Stephen Frost wrote:
* David Fetter ([EMAIL PROTECTED]) 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
