Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On Fri, May  9, 2014 at 09:53:36AM -0400, Bruce Momjian wrote:
> On Fri, May  9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
> > Gavin Flower <GavinFlower@archidevsys.co.nz> writes:
> > > On 09/05/14 15:34, Bruce Momjian wrote:
> > >> Looks good.  I was thinking the jsonb_ops name could remain unchanged
> > >> and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
> > >> the key and value into a single index entry.
> > 
> > > If you have 'jsonb_combo_ops' - then surely 'jsonb_op' should be called 
> > > 'jsonb_xxx_ops', where the 'xxx' distinguishes that from 
> > > 'jsonb_combo_ops'?  I guess, if any appropriate wording of 'xxx' was too 
> > > cumbersome, then it would be worse.
> > 
> > Yeah, I'm disinclined to change the opclass names now.  It's not apparent
> > to me that "combo" is a better choice than "hash" for the second opclass.
> 
> Well, if we are optionally hashing json_ops for long strings, what does
> jsonb_hash_ops do uniquely with hashing?  Does it always hash, while
> json_ops optionally hashes?  Is that the distinguishing characteristic? 
> It seemed the _content_ of the indexed value was more important, rather
> than the storage method.

Also, are people going to think that jsonb_hash_ops creates a hash
index, which is not crash safe, even though it is a GIN index?  Do we
have this "hash" confusion anywhere else?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +