Re: Fwd: PATCH: psql boolean display
От | Phil Sorber |
---|---|
Тема | Re: Fwd: PATCH: psql boolean display |
Дата | |
Msg-id | CADAkt-hzqFBOUs6JnOJ4Xj1DwUKo_GWLhSy287ye5OXx9+d8HQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Fwd: PATCH: psql boolean display (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Fwd: PATCH: psql boolean display
Re: Fwd: PATCH: psql boolean display |
Список | pgsql-hackers |
On Sun, Sep 2, 2012 at 1:13 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > ---------- Forwarded message ---------- > From: Pavel Stehule <pavel.stehule@gmail.com> > Date: 2012/9/1 > Subject: PATCH: psql boolean display > To: Phil Sorber <phil@omniti.com> > > > Hello > > I am looking to your patch: > > I have only one note. I don't think so using any text for values > "true" and "false" is good idea. I don't see a sense of any special > texts like "foo", "bar" from your example. > > More strict design is better - I wrote simple modification - it is > based on psql psets - and it add new configuration settings "boolstyle > [char|word]". A advantage of this design is consistency and possible > autocomplete support. > > Regards > > Pavel > > > > postgres=> select true, false; > bool │ bool > ──────┼────── > t │ f > (1 row) > > postgres=> \pset boolstyle word > Bool output style is word. > postgres=> select true, false; > bool │ bool > ──────┼─────── > true │ false > (1 row) > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > What you are proposing sounds like it would be better suited to a server side GUC. Based on the discussion in the thread that said true/false was the SQL standard and we were doing it incorrectly as t/f but could not change for legacy reasons. We could even change the default but give users a way to revert to the old behavior. Similar to the bytea_output GUC. Maybe add the GUC for 9.3 but not change the default behavior until 10.0. What my patch was intended to do was let the end user set boolean output to any arbitrary values. While foo/bar is pretty useless, it was meant to reinforce that it was capable of any arbitrary value. I can think of a decent list of other output an end user might want, such as: true/false yes/no y/n on/off 1/0 enabled/disabled Plus the different capitalized forms.
В списке pgsql-hackers по дате отправления: