| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump.c |
| Date: | 2011-09-11 19:18:13 |
| Message-ID: | 4E6D0975.1010804@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09/11/2011 02:50 PM, Tom Lane wrote:
> In particular, I think that discovering a safe dump order for a selected
> set of objects is a pretty key portion of pg_dump's functionality.
> Do we really want to assume that that needn't be included in a
> hypothetical library?
Maybe. Who else would need it?
> Other issues include:
>
> * pg_dump's habit of assuming that the SQL is being generated to work
> with a current server as target, even when dumping from a much older
> server. It's not clear to me that other clients for a library would
> want that behavior ... but catering to multiple output versions would
> kick the complexity up by an order of magnitude.
Good point. Maybe what we need to think about instead is adding some
backend functions to do the sort of things I want. That would avoid
version issues and have the advantage that it would be available to all
clients, as well as avoiding possible performance issues you mention.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2011-09-11 19:30:11 | Double sorting split patch |
| Previous Message | Andrew Dunstan | 2011-09-11 18:58:57 | psql additions |