On 2014-05-09 10:26:48 -0400, Bruce Momjian wrote: > 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 <gavinflo...@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?
The operator class has to be specified after the USING GIN in CREATE INDEX so I think that rest is neglegible. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
