Re: Patch for pg_dump
От | Andrew Dunstan |
---|---|
Тема | Re: Patch for pg_dump |
Дата | |
Msg-id | 4601BDF3.50401@dunslane.net обсуждение исходный текст |
Ответ на | Re: Patch for pg_dump (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > 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. > > > Along similar lines, what happened to the idea of pre-data and post-data dump subsets that was discussed not so long ago, unless my memory is playing tricks again? cheers andrew
В списке pgsql-hackers по дате отправления: