On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > I suggest you review the original thread on this subject before a line was > ever written. "multiple" (see subject line on this whole thread) is clearly > what is being asked for. Making people turn that into a single argument is > not what was envisaged. See for example Pavel's original example involving > use of xargs where that's clearly not at all easy.
I couldn't see why it would matter to have multiple -C, but xargs having -n which consumes more than 1 stdin item is indeed an use case. When reading the thread I didn't notice it since I didn't know what -n does.
But multiple -C is confusing since it suggests the groupings matter
I disagree
The user can choose the best grouping for better readability and maintainability.
There is not any real reason to limit
a) number of usage -C option
b) number of commands inside -C option.
The multiple usage of -C option is necessary - the backslash commands with params have to be alone or last in group
But if it is not necessary, then requirement only one commands per option is unfriendly
Regards
Pavel
.
To me at least, it feels weird that -C "SELECT 1; SELECT 2;" -C "SELECT 3;" is the same as -C "SELECT 1; SELECT 2; SELECT 3" and lots of other combinations. It feels like the split in groups must mean something, otherwise why would you support/use multiple groups?
Upthread at least somebody thought each -C group would/should be a transaction and I can see this confusion coming up again and again, enough to question whether this patch is an improvement over the current situation. And if a single -C is too small of an improvement, maybe it means the whole idea should be dropped. I think the same of multiple -f as well: to me they're more confusing than helpful for the same reason.