Re: Fwd: PATCH: psql boolean display - Mailing list pgsql-hackers

2012/9/2 Phil Sorber <phil@omniti.com>:
> 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.

If you have these different requests, then you can use enums - or you
can use own formatting function. There is relative strong
recommendation don't use implicit formatting based on database
configuration from application and inside application use explicit
formatting anywhere. I don't thing so using GUC for boolean datatype
is good idea.

Using just chars 't' and 'f' is unlucky design, that must be respected
due compatibility reasons. You don't need to solve it usually, because
transformation from chars to words can do application or database
driver - so I understand this as client issue - psql issue in this
case. And I really don't see any sense for unlimited bool output - in
simple tool like psql. It can be nice to fix issue with chars, because
chars are not too pronounced, but we don't need to supply enums.

Regards

Pavel