On Fri, Oct 07, 2005 at 11:47:26AM +0300, WireSpot wrote: > On 10/7/05, David Fetter <david@xxxxxxxxxx> wrote: > > Here's my thoughts on a summary: > > > > [-t [table | glob]]... # 0 or more -t options > > [-T [table | glob]]... # 0 or more -T options > > [--include-tables-from-file f] > > [--exclude-tables-from-file f] > > > > where globs get expanded just the way they are in psql, and the > > exclude is evaluated after the include to remove any tables where > > they might conflict. I don't think regex matching is needed or > > good. > > > > Does this make sense? > > Sure does, and it looks good. > > But... will the resulting dump be consistent as far as foreign keys > are concerned? Or will the current -t warning still apply (YMMV as > to the consistency of the resulting dump)? I think the latter is better. This is solidly in the realm of prying off cover plates, and the warning is already there :) > If it's my job to ensure foreign key consistency, an option that > only dumps foreign keys and/or omits the foreign keys from the dump > would also be essential... Grepping a full dump, as I said, is not > nice, plus the foreign keys are multi-line which complicates > grepping. I think we can avoid a giant rat hole here by not trying to follow foreign keys. Can we consider following foreign keys a separate feature for later discussion and just go with the (not totally trivial) considerations of schema and table inclusion and exclusion? Cheers, D -- David Fetter david@xxxxxxxxxx http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
