Mark Dilger wrote:
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.


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

Attachment: tiny.tgz
Description: GNU Unix tar archive

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to