From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump(all) library |
Date: | 2008-07-26 16:59:10 |
Message-ID: | 488B57DE.1020701@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> * David Fetter (david(at)fetter(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-26 17:20:48 | Re: Executor question |
Previous Message | Simon Riggs | 2008-07-26 16:56:42 | Re: pg_dump additional options for performance |