Re: Fixed length data types issue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixed length data types issue
Date
Msg-id 3052.1157922931@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixed length data types issue  (Mark Dilger <pgsql@markdilger.com>)
Responses Re: Fixed length data types issue  (Mark Dilger <pgsql@markdilger.com>)
Re: Fixed length data types issue  (Gregory Stark <gsstark@mit.edu>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: contrib uninstall scripts need some love
Next
From: "Guido Barosio"
Date:
Subject: Re: contrib uninstall scripts need some love