| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump(all) library |
| Date: | 2008-07-26 16:46:48 |
| Message-ID: | 23815.1217090808@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> What would a libpgdump API look like?
Hmm. Start with requirements:
* Ability to enumerate the objects in a database
* Ability to fetch the "properties" of individual objects
(SQL definition is only one property, eg. pg_dump considers
owner, schema, ACL separately from the CREATE command)
* Ability to identify an appropriate dump order (and perhaps
lower-level manipulations of dependency info, not sure what
might be needed)
* Ability to work with different server versions (not sure how
much that impacts the API, but it's definitely something to keep
in mind while designing)
What else?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-07-26 16:56:42 | Re: pg_dump additional options for performance |
| Previous Message | Stephen Frost | 2008-07-26 16:43:55 | Re: pg_dump additional options for performance |