From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: csv format for psql |
Date: | 2018-03-25 16:02:41 |
Message-ID: | CAFj8pRC_BO7CYbyKVeDCQ5N705cnG0RvU7+0b1cbAcUEG31tkA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
>
> 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)."
Regards
Pavel
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Sitnikov | 2018-03-25 17:11:39 | Re: Backend memory dump analysis |
Previous Message | Tom Lane | 2018-03-25 15:54:54 | Re: WIP: a way forward on bootstrap data |