"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> "Ryan Bradetich" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
