Tom Lane wrote:
> Mark Dilger <pgsql@markdilger.com> 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
peoplewho 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