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