Re: casting BOOL to somthng

sad wrote:
> since you printed it you poke a convention (of casting to string)
>
> if you can print it on screen why not to print it in string?

Allow me an attempt at a philosophical explanation:

The external representation to the API is arbitrary, because it's part 
of the API specification, and it varies.  If you use libpq, you get a 
character 't' or 'f', if you use ECPG you get a C bool (int) datum, if 
you use JDBC, you get a Java bool value, etc.  psql uses libpq, so you 
see 't' or 'f'.  MS Access maybe uses ODBC and you might see a checkbox 
or something.  It's part of the interface definition.

The cast to text, however, is part of the data model, and it has to be 
both natural and universal.  I think you agree that there is no 
universal, obvious correspondence between character strings and boolean 
values, at least not nearly as universal and obvious as the well-known 
correspondence between character strings and numbers.  We could pick 
one arbitrary correspondence and implement it, and if we did we would 
probably pick one that is consistent with the mapping used by libpq and 
other frontends.  But doing that gains no functionality, so why bother?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/