Re: pg_dump feature patch to allow selection of rows to

In order to support some automation, I needed the ability to pull out
subsets of postgres tables in a format which could be loaded into
other postgres databases. Instead of writing a utility to replicate
the functionality in pg_dump, I created a new flag, --where, which
allows you to postpend where (or order or limit or whatever) sql
fragments at the end of the select done by pg_dump.

You must use the --insert option with this so that it will generate
inserts (which is done via select) instead of copy (which is done via
copy).

You almost certain will need to also use the --table option since most
likely the sql fragment will only be valid for one table instead of
all tables.

I find it very useful and hope you do to. This patch was created with
7.x postgresql, but if it doesn't apply cleanly against 8.x, I can
probably update it for you.

Seth Robertson wrote:
> In order to support some automation, I needed the ability to pull out
> subsets of postgres tables in a format which could be loaded into
> other postgres databases.

One alternative would be using CREATE TABLE AS to create a separate
table containing the desired subset, and then using pg_dump to dump that
table.

> Instead of writing a utility to replicate the functionality in
> pg_dump, I created a new flag, --where, which allows you to postpend
> where (or order or limit or whatever) sql fragments at the end of the
> select done by pg_dump.

Neat, but IMHO too much of a kludge for mainline.

-Neil

Neil Conway <neilc(at)samurai(dot)com> writes:
> Seth Robertson wrote:
>> Instead of writing a utility to replicate the functionality in
>> pg_dump, I created a new flag, --where, which allows you to postpend
>> where (or order or limit or whatever) sql fragments at the end of the
>> select done by pg_dump.

> Neat, but IMHO too much of a kludge for mainline.

Yeah, I felt the same --- the fact that it doesn't work for the normal
COPY case renders it a bit too ugly.

regards, tom lane