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/
