Robert Haas <robertmh...@gmail.com> writes: > On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> Both of the operator classes are actually much less flexible than I'd like.
> Maybe we should make *neither* of these the default opclass, and give > *neither* the name json_ops. There's definitely something to be said for that. Default opclasses are sensible when there's basically only one behavior that's interesting for most people. We can already see that that's not going to be the case for jsonb indexes, at least not with the currently available alternatives. Not having a default would force users to make decisions explicitly. Is that what we want? One other point here is that non-default opclasses can't be used in UNIQUE/PRIMARY KEY/EXCLUDE constraints, because there's no place to specify an opclass name in those syntaxes. UNIQUE/PRIMARY KEY don't matter here since these aren't btree opclasses, but is there a use-case for EXCLUDE with any of the supported jsonb operators? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers