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.
