On Mon, Aug 20, 2012 at 7:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
