Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
> <hlinnakangas@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
