On Mon, Mar 10, 2014 at 4:19 AM, Alexander Korotkov
<aekorotkov@gmail.com> wrote:
> Here it is.
So it looks like what you have here is analogous to the other problems
that I fixed with both GiST and GIN. That isn't surprising, and this
does fix my test-case. I'm not terribly happy about the lack of
explanation for the hashing in that loop, though. Why use COMP_CRC32()
at all, for one thing?
Why do this for non-primitive jsonb hashing?
COMP_CRC32(stack->hash_state, PATH_SEPARATOR, 1);
Where PATH_SEPARATOR is:
#define PATH_SEPARATOR ("\0")
Actually, come to think of it, why not just use one hashing function
everywhere? i.e., jsonb_hash(PG_FUNCTION_ARGS)? It's already very
similar. Pretty much every hash operator support function 1 (i.e. a
particular type's hash function) is implemented with hash_any(). Can't
we just do the same here? In any case it isn't obvious why the
requirements for those two things (the hashing mechanism used by the
jsonb_hash_ops GIN opclass, and the hash operator class support
function 1 hash function) cannot be the same thing.
--
Peter Geoghegan