Re: Re: csv format for psql

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.