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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to