Tom, On Fri, Jul 25, 2008 at 12:32 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> 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. This is an interesting idea that I will test out tonight. I did have the following concern looking through src/backend/utils/adt/int8.c: There is code that is optionally compiled based on the INT64_IS_BUSTED pre-processor define. Is this pre-processor define something I should worry about for portability with this plan? After I get uint types implemented, for fun I might try some benchmarks to see if I can detect the int8 overhead on a 32-bit system. > 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 Good to know. Thanks for the link. > 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. Hopefully I will not need the uint8 type. Right now for a project I am looking at I need the uint2 and uint4 types. uint8 support can come later if it is needed or requested. > 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. This sounds excellent! Hopefully by using these operators I will be able to avoid most of the casting to int8 for my use, while still providing the complete functionality for this type. Thanks again for your review and feedback! - Ryan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
