Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-09-11 19:30:11
Subject: Double sorting split patch
Previous:From: Andrew DunstanDate: 2011-09-11 18:58:57
Subject: psql additions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group