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

Re: Adding WHERE clause to pg_dump

From: daveg <daveg(at)sonic(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding WHERE clause to pg_dump
Date: 2008-07-26 00:33:18
Message-ID: 20080726003318.GP24049@sonic.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jul 25, 2008 at 11:17:20PM +0100, Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> 
> > How do we deal with this?
> >
> > pg_dump -w "last_update_timestamp < ..." -t 'table*'
> >
> > What I see is a recipe for inconsistent, un-restorable backups without a
> > user realizing what they have done. The only way to deal with the above
> > is:
> >
> > 1. Wildcards aren't allowed if you have -w
> > 2. You dump everything, if the WHERE clause isn't relevant you just dump
> > the whole table
> 
> There's always 
> 
>   3. Apply the WHERE clause to all tables and if there's a table missing
>      columns referenced in the where clause then fail with the appropriate
>      error.
> 
> Which seems like the right option to me. The tricky bit would be how to deal
> with cases where you want a different where clause for different tables. But
> even if it doesn't handle all cases that doesn't mean a partial solution is
> unreasonable.

Actually, Davy's patch does deal with the case "where you want a different
where clause for different tables".

-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

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-07-26 00:37:25
Subject: Re: Research/Implementation of Nested Loop Joinoptimization
Previous:From: Tom LaneDate: 2008-07-26 00:26:43
Subject: Re: Research/Implementation of Nested Loop Join optimization

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