Re: PATCH: psql boolean display

From: Phil Sorber <phil(at)omniti(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: psql boolean display
Date: 2012-08-21 03:55:52
Message-ID: CADAkt-hsYcz=0d+PBsv8971eZyvqgxs3y6mVFbuJaGJvcqhhuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 20, 2012 at 7:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> The type itself does output true/false; it's just psql that uses
>> t/f.
>
> No, 't'/'f' is what boolout() returns. The 'true'/'false' results from
> casting bool to text are intentionally different --- IIRC, Peter E.
> argued successfully that this cast behavior is required by SQL spec.
> But we'd already been returning 't'/'f' to applications for far too many
> years to change it. (And that argument has not gotten any weaker since
> then. Keep in mind that Postgres was returning 't'/'f' for bool years
> before the SQL spec even had a boolean type.)
>
> If we're going to do something like this at all, I agree that psql is
> the place to do it, not the server. But my beef with this patch is that
> it's thinking too small --- why would bool be the only type that
> somebody would want to editorialize on the display of? I'd rather see
> some general "substitute this for that in display of columns of type X"
> feature.
>
> regards, tom lane

Sorry, was on my phone before and couldn't type the response I wanted to.

I like where your head is with the more general case, and I tried to
think along those lines too, but I could not come up with a grand
unifying way to do even null and boolean together, never mind other
ways that I hadn't even thought about. The boolean case is a single
datatype where the null case crosses all nullable types. With null you
only have to handle one case, with boolean, you have two.

What I settled upon was the simplest way I could think of with the
most flexibility. In my opinion, the utility of this patch outweigh's
the niche implementation. I'd welcome other approaches that covered
this in a more generic way, I just can't think of any that aren't
overly complex.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-08-21 04:24:29 Re: temporal support patch
Previous Message Tatsuo Ishii 2012-08-21 03:16:11 TODO