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: