summaryrefslogtreecommitdiff
path: root/src/backend/access/hash
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-10-12 14:54:08 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-10-12 14:54:08 -0400
commit5c80642aa8de8393b08cd3cbf612b325cedd98dc (patch)
tree80623f22630197306af009041c87705edf06ea73 /src/backend/access/hash
parent8518583cdb10340bab3464121629a1a9ec387afa (diff)
downloadpostgresql-5c80642aa8de8393b08cd3cbf612b325cedd98dc.tar.gz
Remove unnecessary int2vector-specific hash function and equality operator.
These functions were originally added in commit d8cedf67a to support use of int2vector columns as catcache lookup keys. However, there are no catcaches that use such columns. (Indeed I now think it must always have been dead code: a catcache with such a key column would need an underlying unique index on the column, but we've never had an int2vector btree opclass.) Getting rid of the int2vector-specific operator and function does not lose any functionality, because operations on int2vectors will now fall back to the generic anyarray support. This avoids a wart that a btree index on an int2vector column (made using anyarray_ops) would fail to match equality searches, because int2vectoreq wasn't a member of the opclass. We don't really care much about that, since int2vector is not meant as a type for users to use, but it's silly to have extra code and less functionality. If we ever do want a catcache to be indexed by an int2vector column, we'd need to put back full btree and hash opclasses for int2vector, comparable to the support for oidvector. (The anyarray code can't be used at such a low level, because it needs to do catcache lookups.) But we'll deal with that if/when the need arises. Also worth noting is that removal of the hash int2vector_ops opclass will break any user-created hash indexes on int2vector columns. While hash anyarray_ops would serve the same purpose, it would probably not compute the same hash values and thus wouldn't be on-disk-compatible. Given that int2vector isn't a user-facing type and we're planning other incompatible changes in hash indexes for v10 anyway, this doesn't seem like something to worry about, but it's probably worth mentioning here. Amit Langote Discussion: <d9bb74f8-b194-7307-9ebd-90645d377e45@lab.ntt.co.jp>
Diffstat (limited to 'src/backend/access/hash')
-rw-r--r--src/backend/access/hash/hashfunc.c8
1 files changed, 0 insertions, 8 deletions
diff --git a/src/backend/access/hash/hashfunc.c b/src/backend/access/hash/hashfunc.c
index 614f4ff2f5..12dce2e2b4 100644
--- a/src/backend/access/hash/hashfunc.c
+++ b/src/backend/access/hash/hashfunc.c
@@ -131,14 +131,6 @@ hashoidvector(PG_FUNCTION_ARGS)
}
Datum
-hashint2vector(PG_FUNCTION_ARGS)
-{
- int2vector *key = (int2vector *) PG_GETARG_POINTER(0);
-
- return hash_any((unsigned char *) key->values, key->dim1 * sizeof(int16));
-}
-
-Datum
hashname(PG_FUNCTION_ARGS)
{
char *key = NameStr(*PG_GETARG_NAME(0));