Re: Re: csv format for psql - Mailing list pgsql-hackers

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":-)

--
Fabien.