2018-06-03 19:16 GMT+02:00 David G. Johnston <david.g.johns...@gmail.com>:
> On Sunday, June 3, 2018, Pavel Stehule <pavel.steh...@gmail.com> wrote: >> >> >> \pset fieldsep ; >> \pset format csv >> >> I don't like when one command overwrite settings of some other command. >> We can introduce some similar like GUC where default values from configure >> file can be overwritten by custom setting for session. So I am able to >> thinking about some settings >> >> like >> >> \pset csv_default_separator >> \pset csv_default_header >> >> Then there is question to simplify all and use \pset csv_separator, and >> csv format independent of fieldseparator value? It is possible, but I don't >> think so have more option for similar value is good idea (for interactive >> mode). >> > > Having a dedicated option seems infinitely better than adding new settings > for defaults and having to keep track of whether the shared field separator > is a default versus a user specified value. > > Recently we reworked server GUCs to avoid this kind of unset/default > behavior. I don't see how introducing or relying upon it in psql would be > an advantage. > I am thinking so psql design is little bit special, because we should to think about more modes - interactive and not interactive, and our goal should be some consistency from user perspective in interactive mode. But for me, the special CSV options are acceptable - although little bit unfriendly from user perspective. > At this point -1, keep the status quo, for any implementation that tries > to make the unaligned mode field separator perform double duty. I'm open, > but unlikely, to be convinced that it can be done without unforeseen bad > side effects and degraded usability. > With respect to your opinion, I don't agree so current status is good - mainly in this case. Regards Pavel > David J. >
