Re: [PgFoundry] Unsigned Data Types [1 of 2]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: "Ryan Bradetich" <rbradetich(at)gmail(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2]
Date: 2008-09-07 00:10:04
Message-ID: 27485.1220746204@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> postgres=# select -256::uint1;
>>> ERROR: uint1 out of range
>>
>> No, that's just because this is parsed as -(256::uint1)

> actually, i thought that case is right but the -255::uint1 returning a
> negative number (aka -255) is what bothers me

Well, again, that's -(255::uint1). I suppose uint1 hasn't got a
negation operator (what would it do??), so probably the sequence of
events is to form 255::uint1, then implicitly promote it to some signed
type or other (most likely int4), then negate. Not much to be done
about this unless you want to get rid of the implicit coercion to signed
types, which would probably defeat most of the purpose.

Now, if (-255)::uint1 fails to throw error, that would be a bug IMHO.
Casting any negative value to uint ought to fail, no?

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message David Rowley 2008-09-07 02:03:57 Re: [PATCHES] TODO item: Implement Boyer-Moore searching (First time hacker)
Previous Message David Rowley 2008-09-06 23:25:07 Re: [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)