Re: Re: csv format for psql - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Re: csv format for psql
Date
Msg-id alpine.DEB.2.20.1803240934500.13537@lancre
Whole thread Raw
In response to Re: Re: csv format for psql  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Re: csv format for psql
List pgsql-hackers
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.

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

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.

Also, if I do "\pset fielsep ''" then the \pset output does not allow to 
distinguish between the unset state and set to empty state.

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.

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

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: csv format for psql
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench randomness initialization