Re: TODO: Fix CREATE CAST on DOMAINs

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 -> int4 cast 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