Re: Re: csv format for psql

2018-03-25 18:02 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2018-03-25 15:21 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
>>
>>
>> Hello Pavel,
>>
>> [...]
>>>>
>>> it is correct. Default format is aligned, that doesn't use fieldsep.
>>>
>>
>> My comment is that currently fieldsep is kind of a variable, the value of
>> which is displayed and reliable wrt commands executed afterwards, and the
>> proposed approach changes that by adding a new "default" state.
>>
>> [...]
>>>>
>>> There should be similar mechanism like fieldsep_zero, that reset
>>> settings.
>>> Some like fieldsep_default.
>>>
>>
>> The user-visible fieldsep_zero is a horrible hack which exposes the fact
>> that C strings cannot hold character zero because it is the end of string
>> marker. The user should not have to care! I wish it would be simply
>> removed, and that "\pset fieldsep '\0'" or something like that would do the
>> trick.
>>
>> Having another one of these, which would create 4 boolean states which
>> would have to be interpreted (eg if default is true and zero is true and
>> sep is ';', and format is csv, what will I get?) by the user to guess what
>> is going to happen looks unhelpful.
>>
>> For me adding another user-visible fieldsep-related boolean a no go.
>>
>> Also, if I do "\pset fielsep ''" then the \pset output does not allow to
>>>> distinguish between the unset state and set to empty state.
>>>>
>>>
>>> This is question - how to fieldsep be related to current format. Aligned
>>> format doesn't use fieldsep.
>>>
>>
>> For me \pset reflects the current value of output options. With the
>> proposed approach it does not mean that anymore, as already said above.
>>
>> I would not expect a committer to accept such a strange no-possible-return
>>>> to previous state because of a hidden state (whether fieldsep has been
>>>> set
>>>> or not in the past) behavior.
>>>>
>>>
>>> This design is very similar to already implemented fieldsep_zero - look
>>> to
>>> code. It is nothing new.
>>>
>>
>> Alas you are right. I suggest not to go on the same path again:-)
>>
>> So I can do better?
>>>
>>
>> Dunno. Possibly.
>>
>> 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?
>

implemented in attached patch

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

it can be clean from following result

postgres=# \pset fieldsep
User didn't specified field separator.
Current format doesn't specify default field separator.
postgres=# \pset fieldsep ;
Field separator is ";".
postgres=# \pset fieldsep
Field separator is ";".

fieldsep_default was removed

Regards

Pavel

> Regards
>
> Pavel
>
>
>>
>> --
>> Fabien.
>>
>
>