Re: Patch for pg_dump

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

In response to

Responses

Browse pgsql-hackers by date

  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?