Обсуждение: Unsigned ints

Hi,

    I know I'm a bit early to submit stuff for 7.2, but attached is a patch
(agains 7.1RC1) to add uint2 and uint4 as new types. I haven't put in
all the possible combinations of signed and unsigned ints as arguments
to operators -- I was going insane just doing it for all combinations of
uint2 and uint4. If anything is missing, please let me know and I'd
appreciate it if somebody could do some sanity checking on the patch, as
this is the first time I've actually inserted a new type into the
catalog.

Also, some other databases (Compaq Himalaya) use

    SMALLINT UNSIGNED
    INTEGER UNSIGNED

for these types. Dunno whether a type consisting of 2 words is going to
break the parser completely. If there are any problems with the patch,
please let me know as well -- not sure I've built it in the correct way.

Regards,

Adriaan

Uggh, this needs some help. I've got the problem that I can insert a
value bigger than MAXINT into an int8 column, but when I try to do the
same for a uint4 column, the parser coerces it into an int4, as in:

test=# insert into tint8 values (3043140617);
INSERT 30254 1
test=# insert into tuint4 values (3043140617);
ERROR:  Attribute 'a' is of type 'uint4' but expression is of type
'float8'       You will need to rewrite or cast the expression
test=# insert into tuint4 values (3043140617::uint4);
INSERT 30255 1


Apparently this happens in parse_target.c, from where it calls
CoerceTargetExpr from where it calls routines in parse_coerce.c.

At this point I decided that somewhere in the definition of the type
there must be a way of specifying how values can be transformed. Can
anybody explain to me what I need to change to make this work? Without
this ecpg cannot work with unsigned ints, so explicit casting is not an
option.

Cheers!

Adriaan

> At this point I decided that somewhere in the definition of the type
> there must be a way of specifying how values can be transformed. Can
> anybody explain to me what I need to change to make this work? Without
> this ecpg cannot work with unsigned ints, so explicit casting is not an
> option.

The large integer-like value is silently transformed into a float8 by
the scanner (very early in the parsing stage). You have not provided a
function to transform float8 into uint4, which if you do so will fix
your problem. Do a
 create function uint4(float8)...

and the type coersion code will understand how to convert one into the
other.
                    - Thomas

Adriaan Joubert <a.joubert@albourne.com> writes:
> Uggh, this needs some help. I've got the problem that I can insert a
> value bigger than MAXINT into an int8 column, but when I try to do the
> same for a uint4 column, the parser coerces it into an int4, as in:

See past discussions about appropriate handling of unlabeled numeric
constants.  This is a tricky area that needs a thoroughgoing rethink.
If you go into it with only "fix uint4" in mind then you will almost
certainly make things worse.
        regards, tom lane

Tom Lane wrote:
> See past discussions about appropriate handling of unlabeled numeric
> constants.  This is a tricky area that needs a thoroughgoing rethink.
> If you go into it with only "fix uint4" in mind then you will almost
> certainly make things worse.

Gosh, you were certainly right there! Now inserting 65535 works, but
inserting 65536 gives me 0 unless I cast to uint4!

Searching the mailing list is not working for the individual mailing
lists (I get Error: File Not Found - Did you enter the correct domain
name, or URL? from ReadySetNet), and searching through all the files at
uni-erlangen.de turned up nothing. 

Can somebody tell me when that discussion took place? Or tell me where
to look in the code?

Thanks!

Adriaan