Re: Re: csv format for psql

2018-03-27 11:35 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>