Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Mark Dilger wrote:
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.
I have thought about this some more. I think these are indeed SAFE. The
distinction between SAFE and IMPLICIT should not, I think, be whether the
storage type is identical, but rather whether there is any possible loss of
precision, range, accuracy, etc., or whether there is any change in the
fundamental interpretation of the data when cast from the source to destination
type.
You are going in exactly the wrong direction --- this line of thought is
aiming to make *more* casts possible by default, which is not what we
need, at least not among the collection of base types.
If I understand correctly, you are worried about two issues: ambiguity and
performance. You don't want the system to be slower from the extra searching
needed to find possible multiple step casts, and you don't want any new
ambiguity where the system can't deterministically decide which choice of
cast(s) should be used. Is that right?
If the system chooses cast chains based on a breadth-first search, then the
existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8 chain,
or an int2 -> int3 -> int4 -> int8 chain, or in fact any chain at all, because
the int2 -> int8 cast is the shortest.
So the code to search chains should only be invoked in what would currently be
an *error condition*, that being that the SQL includes a request for a cast that
cannot be resolved without chaining.
Since the chaining code would be new, and the rules for it would be new, we can
still design them however we like (within reason.) I would propose:
1) Shorter chains trump longer chains.
2) When comparing two equal length chains, one made entirely of SAFE casts
trumps one which contains an IMPLICIT cast.
3) When two or more chains remain that cannot be resolved under the above two
rules, the SQL is considered ambiguous and an error condition is raised.
I don't see how this would break any existing valid SQL. But it seems like it
would solve both the DOMAIN problem you mentioned and the oft lamented problem
that adding a new datatype requires quadratically many casts to the system.
mark
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
