David G. Johnston wrote: > Unaligned format could grow its own fieldsep if it wanted to but it can > also just use the default provided fieldsep var whose default value is > pipe. If it did grow one it would need to understand "not set" in order to > preserve existing behavior. We don't have that problem with csv.
fielsep is already owned by the unaligned format. No other format uses fieldsep currently. Why would it needs to grow its own? I don't quite see what you mean here. For csv, Fabien and Peter expressed the opinion that we shouldn't create another fieldsep-like variable specifically for it, but instead reuse fieldsep. That's what my latest patch does. Now it turns out that sharing fieldsep comes with some problems. 1. since a single variable can't have two different default values, we have either to accept '|' as a default csv separator, or introduce some tricks to automagically commute the value. 2. when a user does \pset fieldsep ';' there are doubts on whether this should affect the current mode only, or both, or even the other one when the user goes back and forth between formats. Any proposal where a \pset var value affects by side-effect another pset variable is inconsistent with what has been done until now with these variables, and I expect that side-effects are not exactly sought after in general. 3. the command-line cannot express: use character 'X' for unaligned and 'Y' for csv for the rest of the session. The current patch provides '--csv' to select both the csv format and a comma separator, but when combined with -F, the end result depend on the relative position of the options, which may feel unintuitive or buggy. Again we could tweak that, but only by being inconsistent with how we process other options. Personally I think the benefit of sharing fieldsep is not worth these problems, but I'm waiting for the discussion to continue with more opinions. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
