Re: csv format for psql
От | Pavel Stehule |
---|---|
Тема | Re: csv format for psql |
Дата | |
Msg-id | CAFj8pRD2+bNRiNwLxVgv6Dmvq36Pks8+rOusyJPwZwvZgDAhRw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: csv format for psql ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
2018-06-03 19:16 GMT+02:00 David G. Johnston <david.g.johnston@gmail.com>:
Regards
On Sunday, June 3, 2018, Pavel Stehule <pavel.stehule@gmail.com> wrote:\pset fieldsep ;\pset format csvI 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 settingslike\pset csv_default_separator\pset csv_default_headerThen 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.
Pavel
David J.
В списке pgsql-hackers по дате отправления: