Is there a case for putting a field in more than one split? The current implementation allows this, but it makes it easier to accidentally have more splits than you wanted. The underlying challenge for Doing the Right Thing is that the type is not normally set until PCSetFromOptions(). Any calls to PCFieldSplitSet* will be ignored prior to this. The problem occurs when the user specifies -pc_fieldsplit_*_fields AND the code adds splits with PCFieldSplitSet(IS|Fields). This used to create a bunch of splits which is probably not what anyone asked for, I just pushed a some code that makes command-line split definitions permanent. This isn't entirely satisfactory because there isn't currently a way to get rid of them, but it's better than having lots of spurious splits.
Lisandro, let me know if the current code behaves the way you expect. Jed
