On Mon, Aug 20, 2012 at 7:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.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.
