Re: Casts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Casts
Date: 2006-08-09 13:54:28
Message-ID: 19578.1155131668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

stark <stark(at)enterprisedb(dot)com> writes:
> I think the ideal combination is having every type have precisely one
> implicit cast "up" the type "tree" and assignment casts down the
> "tree".

No, because for example in the case of the numeric datatypes, that would
result in *every* cross-type operation being done in NUMERIC. Do you
really want, for example, "bigint var = integer constant" to be
interpreted as "var::numeric = const::numeric"? (Hint: you'll lose the
benefit of any index on the var.)

Actually it's worse than that, because the top of the numeric datatype
hierarchy is float8 not numeric; this is more or less forced by SQL's
rules about exact vs inexact arithmetic. So your proposal would really
reduce to doing all cross-type arithmetic in float8 ... which would
at least be a lot faster than numeric, but it's not gonna fly from an
accuracy point of view.

What we want, and what the existing pg_cast rules give us, is a rule
that an operation between two different numeric types is done in the
"wider" of those two types. You could probably propose some explicit
representation of this concept that would be more compact than the
present pg_cast table --- but it would also be less flexible. I don't
really see much to be gained that way.

regards, tom lane

In response to

  • Re: Casts at 2006-08-09 11:21:40 from stark

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2006-08-09 14:01:13 Re: proposal for PL packages for 8.3.
Previous Message Hannu Krosing 2006-08-09 13:52:25 Re: Forcing current WAL file to be archived