Re: Feature: give pg_dump a WHERE clause expression

On Sun, 2008-06-01 at 15:47 -0400, Tom Lane wrote:
> Davy Durham <pubaddr5@davyandbeth.com> writes:
> > So, if this patch is not acceptable as-is, what would you feel about
> > this:
> >         I could enhance the -t/--table=NAME option to accept more than a
> >         simple NAME.  Rather it could accept something in the form:
>
> >                 --table=<table_name>:<where-clause expression>
>
> Well, that would at least address the complaint that it doesn't scale
> to multiple tables, but the whole thing still seems like a frammish
> that will never see enough use to justify maintaining it.
>

The code is not all that much to maintain as it is, and making it an
addition to an existing parameter instead of a new one may not increase
the code size by much more at all.

BTW- I looked it up, and mysqldump supports such an option as mine, but
it too is global for all tables and cannot be specified per table
AFAICT.

> (BTW, what will you do with a table whose name contains a colon?)
>

I thought about that, but didn't know if tables could contain a colon or
not, but I see that this is possible by enclosing the table name in
double-quotes.  I suppose they could escape the colon as I believe they
may have to do if a table contains  '*', or '?'  ??  Is there another
character that is more appropriate?


Another option I just thought about was to leave the -w/--where flag in
place, but it applies to all subsequent -t/--table flags..

So you could do something like:
    pg_dump -w 'expr1' -t tab1 -t tab2 -w 'expr2' -t tab3

So that the expr1 filters tab1 and tab2, and expr2 filters tab3..

This should be a simple modification to the existing patch to make the
where clause tracked per table rather than merely a global variable.

However there the becomes an importance on the order that args are given
to pg_dump which you may object to.   But then again, if order of the
tables in the dump file matters, then the -t/--tables flags already
indicate what order the tables will be dumped.  (By pointing this out, I
mean there may already be an importance of argument order in some
circumstances)

This also solves the ':' syntax problem you mentioned above.


>             regards, tom lane
>