Re: Re: csv format for psql

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

In response to

Responses

Browse pgsql-hackers by date

  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