Re: PATCH: psql boolean display

2012/8/20 Thom Brown <thom@linux.com>:
> On 20 August 2012 22:10, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> 2012/8/20 Robert Haas <robertmhaas@gmail.com>:
>>> On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber <phil@omniti.com> wrote:
>>>> I am providing a patch to allow you to change the output of a boolean
>>>> value in psql much like you can do with NULL. A client requested this
>>>> feature and we thought it may appeal to someone else in the community.
>>>>
>>>> The patch includes updated docs and a regression test. The code
>>>> changes themselves are pretty simple and straightforward.
>>>>
>>>> Example from the regression test:
>>>>
>>>> SELECT true, false;
>>>>  bool | bool
>>>> ------+------
>>>>  t    | f
>>>> (1 row)
>>>>
>>>> \pset booltrue 'foo'
>>>> \pset boolfalse 'bar'
>>>> SELECT true, false;
>>>>  bool | bool
>>>> ------+------
>>>>  foo  | bar
>>>> (1 row)
>>>>
>>>> \pset booltrue 't'
>>>> \pset boolfalse 'f'
>>>> SELECT true, false;
>>>>  bool | bool
>>>> ------+------
>>>>  t    | f
>>>> (1 row)
>>>>
>>>> As always, comments welcome.
>>>
>>> Why not just do it in the SQL?
>>>
>>> SELECT CASE WHEN whatever THEN 'foo' ELSE 'bar' END AS whatever;
>>
>> I understand this motivation - although I was more happy with server
>> side solution.
>
> Wouldn't a server-side solution risk breaking many things that depends
> on such a representation?  You wouldn't be able to pick and choose
> what comes out of the server on a per-application basis unless you use
> cumbersome CASE clauses in every query that returns boolean data.
>
> It sounds like keeping it at the application level is the least
> disruptive, and there is a precedent for such changes, such as NULL
> representation.

It is similar to datetime formatting or to number formatting.

Sometimes it is issue for some untyped languages because 't' or 'f'
has not adequate sense - but it is unfriendly when somebody working
with console. console based solution like proposed patch is probably
the most less evil solution. Using 't' and 'f' was not a best idea.


>
> --
> Thom