Re: pg_dump.c

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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