On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sula...@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. The logic in the rest of the extended hash functions is same as the standard one. Attaching patch 0002 for the reviewer's testing. Regards, Amul
0001-add-optional-second-hash-proc-v2-wip.patch
Description: Binary data
0002-test-Hash_functions.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
