Re: casting BOOL to somthng

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: sad <sad(at)bankir(dot)ru>, Michael Glaesemann <grzm(at)myrealbox(dot)com>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: casting BOOL to somthng
Date: 2004-09-01 06:59:08
Message-ID: 200409010859.08037.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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/

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Michael Glaesemann 2004-09-01 07:03:51 Re: casting BOOL to somthng
Previous Message sad 2004-09-01 06:43:06 casting UNKNOWN to REGCLASS