On Sun, 2008-06-01 at 15:47 -0400, Tom Lane wrote:
> Davy Durham <[EMAIL PROTECTED]> 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

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

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

>                       regards, tom lane

Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to