From: Peter Eisentraut <peter_e@gmx.net>
To: sad <sad@bankir.ru>, Michael Glaesemann <grzm@myrealbox.com>
Subject: Re: casting BOOL to somthng
Date: Wed, 1 Sep 2004 08:59:08 +0200
User-Agent: KMail/1.5.1
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>,
	pgsql-sql@postgresql.org
References: <200408311306.25545.sad@bankir.ru>
	<8AF2CE57-FBE1-11D8-A2A0-000A95C88220@myrealbox.com>
	<200409010955.45834.sad@bankir.ru>
In-Reply-To: <200409010955.45834.sad@bankir.ru>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200409010859.08037.peter_e@gmx.net>

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/