Re: Re: csv format for psql

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
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 13:21:03
Message-ID: alpine.DEB.2.20.1803251438060.8109@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-25 15:54:54 Re: WIP: a way forward on bootstrap data
Previous Message MauMau 2018-03-25 13:15:52 Re: [bug fix] ECPG: freeing memory for pgtypes crashes on Windows