Re: [HACKERS] discussion on proposed int8_ops patch - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] discussion on proposed int8_ops patch
Date
Msg-id 36D2EDB2.8F0717FA@alumni.caltech.edu
Whole thread Raw
In response to discussion on proposed int8_ops patch  (Ryan Bradetich <rbrad@hpb50023.boi.hp.com>)
List pgsql-hackers
> Enclosed below I have a patch to allow a btree index on the int8 type.
> I would like some feedback on what the hash function for the int8 hash 
> function in the ./backend/access/hash/hashfunc.c should return.
> Also, could someone (maybe Tomas Lockhart?) look-over the patch and 
> make sure the system table entries are correct?

I've got the patches and have applied them (with a bit of fix-up) to my
current source tree. I would like to look at them in more detail before
committing them to the source tree, but I'm sure you've gotten most of
the important stuff.

istm that the int8 hash function can look just like the int4 hash
function, coercing the int8 input down to int4 first. afaik this isn't a
problem, in that int8->int4 overflows are not signaled. I've enabled
this hash strategy in your code.

> P.S. I claimed the following OID's for this implimentation:
>         754 and 842 (for the btree index)
>         949 for the hash index (not totally implimented yet.)
> I got these by using the ./include/catalog/unused_oids script.

Those should be fine, and that was the right way to choose them.

Sorry that I'm out of town until next week, but I should be able to
finish things then. Thanks for the patches.
                   - Tom


pgsql-hackers by date:

Previous
From: Brian P Millett
Date:
Subject: postmaster failure with 2-23 snapshot
Next
From: Michael Davis
Date:
Subject: RE: [GENERAL] Transaction logging