Mark Dilger wrote:
> 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 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.
>
I've created the int1 and int3 types, with casts to/from each other as
well as to/from int2, int4, int8, float4, float8, and numeric. They
also have comparison operators for themselves, though you have to use
casts if you want to compare against other numeric types.
int1 works perfectly, as far as I can tell. int3 works great in memory,
but can't be stored to a table. The problem seems to be that
store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
me to pass int3 by reference. But when I pass either of these types by
reference the backend exits when trying to store to a table.
Does anybody know whether storing data "by reference" works for data
smaller than 4 bytes? If not, then I seem to be out of options for
creating a 3-byte datatype. This would also seem to prevent the
creation of an ascii3 type as well.
mark