Re: Adding WHERE clause to pg_dump

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "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-25 22:17:20
Message-ID: 87iquthamn.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-25 23:16:24 Re: pg_dump additional options for performance
Previous Message Gregory Stark 2008-07-25 22:10:54 Re: Research/Implementation of Nested Loop Join optimization