Hello 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 tried to research them as much as I 
could, but some of them are still not clear to me.

Thanks,
-Ryan

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.  I hope they were 
not being resererved for something els4.


*** ./backend/access/hash/hashfunc.c.orig	Mon Feb 22 15:30:41 1999
--- ./backend/access/hash/hashfunc.c	Mon Feb 22 15:31:32 1999
***************
*** 32,37 ****
--- 32,49 ----
  	return ~key;
  }
  
+ /*
+  * I'm not sure how to impliment this hash function
+  * -Ryan (2/22/1999)
+  */
+ #ifdef NOT_USED
+ uint32
+ hashint8(uint64 *key)
+ {
+ 	return ~((uint32)key);
+ }
+ #endif /* NOT_USED */
+ 
  /* Hash function from Chris Torek. */
  uint32
  hashfloat4(float32 keyp)
*** ./backend/access/nbtree/nbtcompare.c.orig	Mon Feb 22 14:14:56 1999
--- ./backend/access/nbtree/nbtcompare.c	Mon Feb 22 15:02:41 1999
***************
*** 40,45 ****
--- 40,56 ----
  }
  
  int32
+ btint8cmp(int64 *a, int64 *b)
+ {
+ 	if (*a > *b)
+ 		return 1;
+ 	else if (*a == *b)
+ 		return 0;
+ 	else
+ 		return -1;
+ }
+ 
+ int32
  btint24cmp(int16 a, int32 b)
  {
  	return ((int32) a) - b;
*** ./include/catalog/pg_amop.h.orig	Mon Feb 22 14:14:37 1999
--- ./include/catalog/pg_amop.h	Mon Feb 22 15:42:14 1999
***************
*** 168,173 ****
--- 168,183 ----
  DATA(insert OID = 0 (  403 426 521 5 btreesel btreenpage ));
  
  /*
+  *	nbtree int8_ops
+  */
+ 
+ DATA(insert OID = 0 (  403 754 412 1 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 414 2 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 410 3 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 415 4 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 413 5 btreesel btreenpage ));
+ 
+ /*
   *	nbtree oid_ops
   */
  
***************
*** 338,343 ****
--- 348,364 ----
  DATA(insert OID = 0 (  405	423  670 1 hashsel hashnpage ));
  /* int4_ops */
  DATA(insert OID = 0 (  405	426   96 1 hashsel hashnpage ));
+ 
+ /*
+  * Add this when I figure out the int8 hash function.
+  * -Ryan (2/22/1999)
+  */
+ 
+ #ifdef NOT_USED
+ /* int8_ops */
+ /* DATA(insert OID = 0 (  405	426   96 1 hashsel hashnpage )); */
+ #endif
+ 
  /* oid_ops */
  DATA(insert OID = 0 (  405	427  607 1 hashsel hashnpage ));
  /* oid8_ops */
*** ./include/catalog/pg_amproc.h.orig	Mon Feb 22 14:14:27 1999
--- ./include/catalog/pg_amproc.h	Mon Feb 22 14:57:54 1999
***************
*** 92,97 ****
--- 92,98 ----
  DATA(insert OID = 0 (403  435  404 1));
  DATA(insert OID = 0 (403  436  948 1));
  DATA(insert OID = 0 (403  437  828 1));
+ DATA(insert OID = 0 (403  754  842 1));
  DATA(insert OID = 0 (403 1076 1078 1));
  DATA(insert OID = 0 (403 1077 1079 1));
  DATA(insert OID = 0 (403 1114 1092 1));
*** ./include/catalog/pg_opclass.h.orig	Mon Feb 22 14:13:53 1999
--- ./include/catalog/pg_opclass.h	Mon Feb 22 14:26:33 1999
***************
*** 93,98 ****
--- 93,100 ----
  DESCR("");
  DATA(insert OID =  714 (	circle_ops		718   ));
  DESCR("");
+ DATA(insert OID =  754 (	int8_ops		 20   ));
+ DESCR("");
  DATA(insert OID = 1076 (	bpchar_ops	   1042   ));
  DESCR("");
  DATA(insert OID = 1077 (	varchar_ops    1043   ));
No differences encountered
*** ./include/catalog/pg_proc.h.orig	Mon Feb 22 14:14:16 1999
--- ./include/catalog/pg_proc.h	Mon Feb 22 15:41:57 1999
***************
*** 735,740 ****
--- 735,742 ----
  DESCR("btree less-equal-greater");
  DATA(insert OID = 351 (  btint4cmp		   PGUID 11 f t f 2 f 23 "23 23" 
100 0 0 100  foo bar ));
  DESCR("btree less-equal-greater");
+ DATA(insert OID = 842 (  btint8cmp		   PGUID 11 f t f 2 f 23 "20 20" 
100 0 0 100  foo bar ));
+ DESCR("btree less-equal-greater");
  DATA(insert OID = 352 (  btint42cmp		   PGUID 11 f t f 2 f 23 "23 21" 
100 0 0 100  foo bar ));
  DESCR("btree less-equal-greater");
  DATA(insert OID = 353 (  btint24cmp		   PGUID 11 f t f 2 f 23 "21 23" 
100 0 0 100  foo bar ));
***************
*** 821,826 ****
--- 823,838 ----
  DESCR("hash");
  DATA(insert OID = 450 (  hashint4		   PGUID 11 f t f 2 f 23 "23 23" 
100 0 0 100  foo bar ));
  DESCR("hash");
+ 
+ /*
+  * Add this when I figure out the int8 hash function.
+  * -Ryan (2/22/1999)
+  */
+ #ifdef NOT_USED
+ /* DATA(insert OID = 949 (  hashint8		   PGUID 11 f t f 2 f 23 "20 20" 
100 0 0 100  foo bar )); */
+ /* DESCR("hash"); */
+ #endif /* NOT_USED */
+ 
  DATA(insert OID = 451 (  hashfloat4		   PGUID 11 f t f 2 f 23 "700 
700" 100 0 0 100	foo bar ));
  DESCR("hash");
  DATA(insert OID = 452 (  hashfloat8		   PGUID 11 f t f 2 f 23 "701 
701" 100 0 0 100	foo bar ));
No differences encountered
*** ./include/utils/builtins.h.orig	Mon Feb 22 15:05:19 1999
--- ./include/utils/builtins.h	Mon Feb 22 15:06:17 1999
***************
*** 163,168 ****
--- 163,169 ----
   */
  extern int32 btint2cmp(int16 a, int16 b);
  extern int32 btint4cmp(int32 a, int32 b);
+ extern int32 btint8cmp(int64 *a, int64 *b);
  extern int32 btint24cmp(int16 a, int32 b);
  extern int32 btint42cmp(int32 a, int16 b);
  extern int32 btfloat4cmp(float32 a, float32 b);

Mon, 22 Feb 1999 16:18:48 -0700 (MST)
Ryan Bradetich <rbrad@hpb50023.boi.hp.com>
discussion on proposed int8_ops patch
> 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

Tue, 23 Feb 1999 18:04:34 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] discussion on proposed int8_ops patch
Applied, though there was some wrapping of the e-mail I had to clean up.

Your hash code looks fine, so I enabled it by removing the ifdef's.  You
could XOR the top int4 bytes with the bottom int4 bytes, but I doubt
there is a portable way to do that, so you are better off just leaving
it as is, where it looks at only the lower int32 bytes.

If you copied how the other entries pointed to other entries, your code
will be fine.

> Hello 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 tried to research them as much as I 
> could, but some of them are still not clear to me.
> 

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 14 Mar 1999 00:10:22 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] discussion on proposed int8_ops patch
> Applied, though there was some wrapping of the e-mail I had to clean 
> up.
> Your hash code looks fine, so I enabled it by removing the ifdef's.  
> > 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 tried to 
> > research them as much as I could, but some of them are still not 
> > clear to me.

*argh* I had responded to Ryan and the list that there were problems
with the patch and that I would fix it up and then apply to the tree.
So don't expect this stuff to work as-is, and now I'll have to figure
out what else has changed :(

Man, I go away for two weeks and look at what happens ;)

                            - Tom

Sun, 21 Mar 1999 15:00:28 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] discussion on proposed int8_ops patch
> > Applied, though there was some wrapping of the e-mail I had to clean 
> > up.
> > Your hash code looks fine, so I enabled it by removing the ifdef's.  
> > > 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 tried to 
> > > research them as much as I could, but some of them are still not 
> > > clear to me.
> 
> *argh* I had responded to Ryan and the list that there were problems
> with the patch and that I would fix it up and then apply to the tree.
> So don't expect this stuff to work as-is, and now I'll have to figure
> out what else has changed :(

Sorry.  I don't remember seeing your comments.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 21 Mar 1999 13:51:38 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] discussion on proposed int8_ops patch