Re: Re: csv format for psql

2018-03-24 10:06 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Pavel,
>
> I'm suggesting to add \csv which would behave like \H to toggle CSV
>>>> mode so as to improve this situation, with a caveat which is that
>>>> toggling back \csv would have forgotted the previous settings (just
>>>> like \H does, though, so would for instance reset to aligned with
>>>> |),
>>>> so it would not be perfect.
>>>>
>>>
>>> this doesn't solve usual format settings by \pset format csv
>>>
>>
> Indeed, it does not. Alas, "format" is not strictly about format but more
> about string escaping.
>
> (2) your proposal as I understand it:
>>>>
>>>> "\pset format csv" may or may not use the fieldsep, depending on
>>>> whether it was explicitely set, an information which is not shown,
>>>> i.e.:
>>>>
>>>> \pset fieldsep # fieldsep separator is "|"
>>>> \pset format csv # would output a,b,c or a|b|c...
>>>>
>>>> Because it depends on whether fieldsep was set explicitely to '|' or
>>>> whether it has this value but it was due to the default.
>>>>
>>>> This kind of unclear behavioral determinism does not seem desirable.
>>>>
>>>>
>>> please, check and test attached patch. It is very simply for usage - and
>>> there is not any unclear behave. Just you should to accept so formats can
>>> have own defaults for separators.
>>>
>>
> I checked, and the behavior is intrinsically strange.
>
> Your patch shows an empty '' fieldsep at startup, which is debatable
> because it is not its actual value.
>

it is correct. Default format is aligned, that doesn't use fieldsep.

>
> psql> \pset # fieldsep '' -- doubtful
>
> ISTM that at the minimum it should show a special "<format-default>" or
> whatever value, which creates some kind of exception because this special
> value cannot be set and special values are a bad thing.
>
> When a format is set, a current default fielsep is shown.
>
> psql> \pset format unaligned
> psql> \pset # fieldsep '|' -- new default shown
> psql> SELECT 1 AS one, 2 AS two;
> one|two
> 1|2
>
> psql> \pset format csv
> psql> \pset # fieldsep ',' -- new default shown
>
> psql> SELECT 1 AS one, 2 AS two;
> one,two
> 1,2
>
> However, if fieldsep is set once, the behaviors changes indefinitely:
>
> psql> \pset fieldsep '|'
> psql> \pset format unaligned
> # unaligned with '|'
>
> psql> \pset format csv
> # csv with '|'
>
>
There should be similar mechanism like fieldsep_zero, that reset settings.
Some like fieldsep_default.

> That is once the fieldsep has been used, you are back to the v4 behavior
> that you are disagreeing with in the first place.
>
> The patch creates an incomplete state automaton which some unreachable
> states, because once a value is set there is no way to switch back to the
> previous "use default" behavior.
>

It is not implemented, but it is small problem

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

The alternative can be words "not used" -- and then you can see difference
between "" and other. But if you see the code, the empty string is used
like info about empty fieldsep now.

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

>
> So I do not think that this proposed version is really satisfactory.
>

So I can do better?

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.

please, check updated patch

Regards

Pavel

>
> --
> Fabien.
>