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 02:01:01
Message-ID: 14681.1155088861@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

stark <stark(at)enterprisedb(dot)com> writes:
> It seems odd to me that implicit casts are checked for when you call a
> function but not when you're implicitly calling a function via a cast. As a
> result there are a *lot* of redundant casts in our catalog, essentially n!
> casts for a domain with n types in it. So for example there are 138 casts
> between the various numeric data types including every possible pairing of
> char, int2, int4, int8, float4, float8, and numeric.

This is intentional. If you explicitly cast type foo to type bar there
should not be any question about what function will be invoked. The
cost is a few more rows in pg_cast ... so what? Adding rows to pg_cast
is not the most painful part of making a new datatype.

As for "the parser ought to be able to find two-step cast pathways",
no thanks. The increase in search time and the decrease in
predictability are both undesirable.

> There has been some fear expressed in the past that too many implicit casts
> create surprising side effects.

Not "some fear" ... we have seen people badly burned, time and time
again, by the ill-considered implicit casts that are already in there.
IMHO we need fewer implicit casts, not more.

regards, tom lane

In response to

  • Casts at 2006-08-08 12:39:25 from stark

Responses

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-09 02:22:26 Re: An Idea for planner hints
Previous Message Mark Dilger 2006-08-09 01:33:33 Re: An Idea for planner hints