Re: pg_dump exclusion switches and functions/types

-----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 greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200610092003
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFFKuPFvJuQZxSWSsgRAjAxAJ9oY5HCM4KxmpLEU56eCMJauHBhFgCfcyDt
R5yf5SKKBeBHJ2gdRlE1Pqs=
=rIxZ
-----END PGP SIGNATURE-----