Re: Feature: give pg_dump a WHERE clause expression

From: daveg <daveg(at)sonic(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Davy Durham <pubaddr5(at)davyandbeth(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Feature: give pg_dump a WHERE clause expression
Date: 2008-06-01 21:32:23
Message-ID: 20080601213223.GU2470@sonic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


On Sun, Jun 01, 2008 at 04:40:15PM -0400, Andrew Dunstan wrote:
> daveg wrote:
> >
> >I can't imagine many of my clients ever writing another C program or even
> >being willing to pay me to do so. While modularizing pg_dump is a fine
> >idea,
> >I don't think it addresses the same set of use cases and users as this
> >proposal.
>
> It's not clear to me that your use case is very compelling. Does your
> foreign database not support import via CSV or XML? Postgres can now
> produce both of these for any arbitrary query.

The foreign database in question is postgresql.

The feature that the proposed patch enables is to create pg_dump custom
format archives for multiple tables with a predicate. No amount of csv or
xml will do that. Contrived example:

pg_dump -Fc --table="*._stats:where ts >= now()::date" -f todays_stats.pgd

If I have not been successful in explaining this clearly, please reply
privately to avoid cluttering the list. If you simply disagree about the
usefulness of the feature, I'm fine with that.

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2008-06-01 22:05:04 Re: [BUGS] BUG #4203: perform dblink() in begin/exception returns wrong SQLSTATE code
Previous Message Andrew Dunstan 2008-06-01 20:40:15 Re: Feature: give pg_dump a WHERE clause expression