Re: [RFC] Unsigned integer support.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ryan Bradetich" <rbradetich(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC] Unsigned integer support.
Date: 2008-07-25 19:32:06
Message-ID: 29540.1217014326@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
> On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
>>> My plans for the example above would be:
>>>
>>> 1. SELECT 1500000000 + 1500000000 --> Throws overflow error.
>>> 2. SELECT 1500000000::uint4 + 1500000000 --> Returns 3000000000::uint4.
>>
>> You could make it work by having a uint4+int4 operator which returns uint4 but
>> then you're going to need a *lot* of operators....

> This was my plan.

Like he says, it's a *lot* of operators, and the point doesn't seem
entirely clear to me. You'll still have overflow cases, they'll just be
in different places.

Consider the idea of not having any uint4-specific arithmetic operators,
but instead providing the following:

* assignment casts from int4 and int8 to uint4
(these throw error if out of range, of course)
* implicit cast from uint4 to int8 (can never fail)

The effect of providing the latter cast would be that any arithmetic
involving a uint4 column would automatically be done in int8. Which
would make it a shade slower than a native implementation, but probably
not enough slower to be a problem --- and you'd avoid having to write
dozens of operators and underlying support functions. Storing into the
uint4 column would work fine with no extra notation because of the
assignment casts.

Moreover, you'd avoid cluttering the system with a pile of cross-type
operators, which we have recently realized are not a good thing, because
they increase the likelihood of "ambiguous operator" problems --- see
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00750.php

For uint8 you'd have to promote to numeric to guarantee no failure
in the implicit cast; which is going to be a rather bigger performance
hit, but I don't really see uint8 as being a type with huge demand.

Now you probably *will* want cross-type comparison operators, if you
are going to support indexing of unsigned columns, so that something
like
uint4col > 42
can be indexed without any casting. But limiting yourself to the six
basic comparison operators certainly makes it a much less bulky project.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-07-25 19:38:07 Re: Adding WHERE clause to pg_dump
Previous Message Simon Riggs 2008-07-25 19:26:35 Re: Adding WHERE clause to pg_dump