2018-03-27 11:35 GMT+02:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > Hello Pavel, > > I'd like to convince you to compromise, because otherwise I'm afraid we > will not get this feature. > > 1. use special default string for formats that doesn't field sep - like >>> >>>> "not used" or some >>>> 2. I can implemet the option fieldsep_default - very similary to >>>> fieldsep_zero to reset fieldsep to default state. >>>> >>>> >>> I strongly dislike option 2, as expressed above. I would >>> enthousiastically >>> review any patch that would aim are removing these "*_zero" options. I >>> might submit it someday. >>> >>> >> I can remove it simply - but a alternative is implementation of some >> \pset_reset command maybe: >> >> \pset reset fieldsep >> >> what do you think? >> > > I think that changing the semantics of \pset is a nonstarter, it should be > only about "output [p]arameter [set]ting", because it has been like that > for the last XX years and people are used to it. > > I'm more unclear about option 1. Maybe it could be managed cleanly. >>> >>> I'm still at odds that it would mean that \pset would not show the actual >>> setting anymore, but something harder to explain, "actual value or some >>> format-specific value, depending". >>> >> >> It can be formulated little bit different - "when a value of field >> separator is not entered, then format specific default is used (if can be >> specified - some formats doesn't allow to specify field separator)." >> > > Well, that is 3 lines of explanations where people thought they were just > setting a simple variable to a simple value, or showing the actual current > value which would be used if needed. > > My opinion is that some of what you are suggesting could have participated > to an alternate and interesting output-parameters-for-psql design, but we > are a much too late to change that. > > The purpose of the patch is just to enable having clean CSV quite easily > from psql, possibly for pg11... Changing the design and the underlying user > visible behavior would require a much wider and difficult to obtain > consensus, and is very unlikely to get in for pg11, if ever. > > The current version allows "--csv" or need two "\pset" to achieve CSV, > without changing the preceding behavior, however unperfect it is... > > Could you live with that with the benefit of getting it in? I do not claim > it is a perfect solution, just that it is a reasonable one.
> The dynamic default changing approach departs too much for the current > user expectations, the user-benefit is not worth it, and committers are > very likely to think like that. > > The only no-surprise, no-behavioral-change, alternative I see is to have a > csv-specific fieldsep. I'm not keen on that one because it is yet another > variable, one has to remember it, and then it asks the question about > recordsep... and I think there are already too many parameters, and more is > not desirable, although I probably could live with that if I can live with > "fieldsep_zero":-) > > I don't share your opinion so introduction csv-specific fieldsep is surprise less. Current design is wrong - this thread is a evidence. And if we introduce csv-specific fieldsep, then we multiply this wrong design. The fix in this direction is renaming fieldsep to fieldsep-unaliagn - but it is probably too big change too. So this design is nothing what I can mark as good solution. I can live with because it is much better than using pipe as separator for csv, and because real impact is small - for almost people it will be invisible - but have not good feeling from it. Are there some possible alternatives? Regards Pavel > -- > Fabien. >
