Re: [RFC] Unsigned integer support.

Hello Tom,

On Thu, Jul 24, 2008 at 10:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
>> I am looking to take advantage of PostgreSQL extensible type system
>> and implement unsigned integer support.
>
> This has been proposed before, and foundered before on the question
> of implicit coercions. If you're willing to make all coercions *to*
> unsigned types be explicit (or at most assignment), then I think
> it can be made to work without breaking anything. But usually the
> folk who ask for this feature are hoping that bare integer literals
> like "42" will get interpreted as unsigned when they want them to be.
> The problem with that wish is illustrated by
>
> select 1500000000 + 1500000000;
>
> These literals might be either int4 or uint4, therefore this command
> might yield either an integer-overflow error or 3000000000::uint4.
> That's not a distinction you can fuzz over --- it's got to be one
> or the other, and backwards compatibility says it'd better be the
> first.

I am in agreement with you on this. Since SQL does not specify
unsigned types, I was assuming only explicit and assignment casts.
I should have probably mentioned that in the RFC. Thanks for
pointing this out.

My main goal for this type is the reduced storage space. I am fine
with people needing to cast to the unsigned types to benefit from the
reduced storage space.

My plans for the example above would be:

1. SELECT 1500000000 + 1500000000 --> Throws overflow error.
2. SELECT 1500000000::uint4 + 1500000000 --> Returns 3000000000::uint4.

>
>> I am hoping the removal of many of the implicit casts in
>> PostgreSQL 8.3 will simplify this task to where this objection can be
>> removed.
>
> The implicit casts we removed were cross-type-category cases.
> If you hope for unsigned types to be considered part of the numeric
> category, there's no guidance for you there. In fact, the real nub
> of the problem is what type shall be initially assigned to an
> integer-looking literal, and how will you get things to behave sanely
> if that initial choice wasn't what was desired. We still have some
> issues around the fact that "42" isn't considered a smallint. Throwing
> in another possible meaning isn't going to help.
>
>> My understanding is the SQL standard does not provide support for
>> unsigned integers, so I am planning on making all casts from unsigned
>> integers to other data types explicit.
>
> It's really the other direction that would be contentious ...
>
> regards, tom lane

Thanks for your comments! I have already started to play around a bit with
the types and will hopefully have some code ready for review / feedback soon.

- Ryan