Re: Patch for pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch for pg_dump
Date
Msg-id 22528.1174517164@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch for pg_dump  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Patch for pg_dump  (Andrew Dunstan <andrew@dunslane.net>)
Re: Patch for pg_dump  ("Dany DeBontridder" <dany118@gmail.com>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> I guess this matches this TODO item:
>         o Allow selection of individual object(s) of all types, not just
>           tables

Well, it's a subset of it, but do we want to accept a patch that's been
designed with only a subset in mind?  I'd like to see a roadmap for what
a complete facility for this would look like, to make sure we aren't
going down a dead end.

One thing that looks particularly dead-end-ish here is the switch name.
We might be well advised to have only long-form switches for these
things, 'cause we'll surely run out of suitable single letters (in fact,
if "Q" is as close as one can get to "function", we already have).

Another question that seems particularly relevant is how the patch scales
up to specifying (a) function's schema name, (b) argument types (in case
the function name is overloaded).

Code-wise, the patch seems a bit of a mess too --- it will certainly not
scale up to dumping some functions and some other things, as one would
expect for instance if one said "pg_dump -Q myfunc -t mytab ...".  It
doesn't even look like it will handle multiple -Q switches.  I think a
minimum expectation is that -Q would work like -t now does.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq cursor support?
Next
From: Alvaro Herrera
Date:
Subject: fixing dllist?