Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
... The argument made upthread that a
quadratic number of conversion operators is necessitated doesn't seem
right to me, given that each type could upcast to the canonical built in
type. (int1 => smallint, int3 => integer, ascii1 => text, ascii2 =>
text, ascii3 => text, etc.)
This would work all right for the string-category cases, since TEXT is
the only thing you really care about having them cast to anyway.
It probably won't work all that well for int1/int3, because you really
want them to coerce implicitly to all the "wider" numeric types.
Otherwise, perfectly sane queries like "int8 + int1" fail.
Part of the issue here is that we deliberately keep the parser from
searching for multi-step coercions. So for example if you only provide
int1->int2 then the existence of up-casts from int2 doesn't help you
use an int1 with anything except int2.
I am not sure whether any problems would be created if you did provide
the full spectrum of up-casts. I remember having argued that there
would be problems with trying to invent uint2/uint4 types, but that was
a very long time ago, before we had pg_cast and some other changes in
the type resolution rules. With the current system it might work OK.
regards, tom lane
Thanks Tom,
I will try this then. I won't be proposing to ever put this in core, as
the increased code size isn't justified for people who aren't using
these types (IMHO). Any further feedback on why this wouldn't work is
appreciated, as it might save me some time learning on my own. But
otherwise I'll post back in a few days when this is finished.
mark
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
