Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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?
Actually it does gain functionality, because there are plenty of times
when you need to manipulate a textual representation of a data value.
We have casts to text for many datatypes already:
castsource | castcontext
-----------------------------+-------------
character | i
character varying | i
"char" | i
name | i
bigint | i
smallint | i
integer | i
oid | i
real | i
double precision | i
macaddr | e
cidr | e
inet | e
date | i
time without time zone | i
timestamp without time zone | i
timestamp with time zone | i
interval | i
time with time zone | i
numeric | i
(20 rows)
and I think it is reasonable to say that we should have them for all
types. My only beef with the above table is that most of these casts
should not be implicitly invokable --- I think you should have to write
an explicit CAST.
As for the "which representation" argument, both consistency and
implementation simplicity say that it should be whatever the datatype's
output function delivers. Indeed it's just a historical accident that
Postgres didn't define the datatype output functions as returning "text"
values in the first place.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
