-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> Sure, but the question is whether that incremental gain in capability > is worth the extra logical complexity. I'm inclined to think that many > more users would get burned by the complexity than would have use for it. > Considering that we've gotten along this long with only the most > primitive selection capabilities in pg_dump, it doesn't seem like > there's an enormous demand for highly refined capabilities. I disagree - we lose a lot of flexibility by taking out the ordering, and, as was pointed out to me when I first started this patch a while ago, we might as well front-load all the complexity and changes now rather than adding them in release by release. I'm also not sure why the regex should be changed to something even more non-standard than the current POSIX ones. Finally, I'm surprised at the apparent willingness at this point to shatter backwards-compatibility with previous -t scripts, as this was an option I raised early on but met strong resistance, thus the current compromise of allowing existing scripts to run unaltered, while adding in the ability to do some regular expressions. The regex stuff was discussed in January, and the patch submitted in July, so it seems a little rushed to be changing the underlying behavior so quickly right now (that behavior being the ability to control which tables and schemas to dump). I think the original post about the request to exclude a single table and still dump other objects is a fair one, but I think we've morphed far beyond solving that problem. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200610092003 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFKuPFvJuQZxSWSsgRAjAxAJ9oY5HCM4KxmpLEU56eCMJauHBhFgCfcyDt R5yf5SKKBeBHJ2gdRlE1Pqs= =rIxZ -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
