From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Dany DeBontridder <dany118(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for pg_dump |
Date: | 2007-03-21 22:46:04 |
Message-ID: | 22528.1174517164@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-03-21 23:15:06 | fixing dllist? |
Previous Message | Tom Lane | 2007-03-21 22:34:05 | Re: libpq cursor support? |