Re: TODO: Fix CREATE CAST on DOMAINs - Mailing list pgsql-hackers

Tom Lane wrote:
> Rereading what I just wrote, it might be as simple as allowing a
> two-step cast in certain cases, only if the first step is a domain to
> base type coercion (which we assume would be specially marked in
> pg_cast).  But the devil is in the details ... and anyway there might
> be a cleaner approach than that.

ISTM casts from a domain to their base type are fundamentally different from 
casts between types.  In general, casting TYPE_X to TYPE_Y requires malloc'ing 
memory for TYPE_Y, and converting the data of TYPE_X into TYPE_Y, possibly with 
loss of accuracy or correctness, etc.  (4-byte or less types are handled on the 
stack, not the heap, but that seems irrelevant to me and I'm only mentioning it 
here to head off any replies along those lines.)  Certainly, having the system 
chain together lots of implicit casts of this sort is scary.  But casting a 
domain to its base type never involves loss of accuracy or correctness, right? 
(Casting from the base type to the domain might not work, on account of the 
domain restrictions forbidding the particular value stored in the base.)

Perhaps we need to be able to register casts with more information than just 
IMPLICIT vs. EXPLICIT.  Perhaps we also need something like SAFE or some other 
term, and then have a rule that no chain of casts chosen by the system (as 
opposed to specified by the user) can contain more than one IMPLICIT cast, but 
can contain unlimited many SAFE casts.

When a domain is created, a SAFE cast from the domain to its base type could 
automatically be generated.

Casts between the existing varchar(n) to text could be marked as SAFE, given 
that the underlying storage scheme for varchar(n) is the same as text.  (Casts 
from text to varchar(n) are not SAFE, because the text might be too long to fit.)

Casts from int2 -> int4, int2 -> int8, and int4 -> int8 would all be SAFE, I 
think, because they are not lossy.  But perhaps I have not thought enough about 
this and these should be IMPLICIT rather than SAFE.

Casts from non-text types to text would remain IMPLICIT, I expect.

If a user created their own type, such as the recent discussion of an int3 type,  they could also create an int3 ->
int4cast marked as SAFE, and from int2 -> 
 
int3 marked as SAFE, and from int3 -> int2 marked as EXPLICIT, and from int4 -> 
int3 marked as EXPLICIT, and could avoid writing all the casts to other integral 
types.

(I've pretty much abandoned the idea of an int3 type because my testing 
convinced me there were no performance advantages to it.  But it serves ok as an  example.)

mark