On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sulamul@gmail.com> wrote: > I have a small query, what if I want a cache entry with extended hash > function instead standard one, I might require that while adding > hash_array_extended function? Do you think we need to extend > lookup_type_cache() as well?
Hmm, I thought you had changed the hash partitioning stuff so that it didn't rely on lookup_type_cache(). You have to look up the function using the opclass provided in the partition key definition; lookup_type_cache() will give you the default one for the datatype. Maybe just use get_opfamily_proc?
Yes, we can do that for
the
partitioning code, but my concern is a little bit
different. I apologize, I wasn't clear enough.
I am trying to extend hash_array & hash_range function. The hash_array and
hash_range function calculates hash by using the respective hash function for
the given argument type (i.e. array/range element type), and those hash
functions are made available in the TypeCacheEntry via lookup_type_cache(). But
in the hash_array & hash_range extended version requires a respective extended
hash function for those element type.
I have added hash_array_extended & hash_range_extended function in the attached
patch 0001, which maintains a local copy of TypeCacheEntry with extended hash
functions. But I am a little bit skeptic about this logic, any
advice/suggestions will be
greatly appreciated.
Instead, in the attached patch, I have modified lookup_type_cache() to
request it to get extended hash function in the TypeCacheEntry.
For that, I've introduced new flags as TYPECACHE_HASH_EXTENDED_PROC, TYPECACHE_HASH_EXTENDED_PROC_FINFO & TCFLAGS_CHECKED_HASH_EXTENDED_PROC, and additional variables in TypeCacheEntry structure to hold extended hash proc information.
The logic in the rest of the extended hash functions is same as the standard
one.
Same for the hash_array_extended() & hash_range_extended() function as well.