Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXuMS-0005X0-Rf for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Apr 2014 15:24:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WXuMS-0005zJ-Ag for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Apr 2014 15:24:24 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXuMQ-0005x9-8G for pgsql-hackers@postgresql.org; Wed, 09 Apr 2014 15:24:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXuMN-0007z7-UR for pgsql-hackers@postgresql.org; Wed, 09 Apr 2014 15:24:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s39FOG5c030138; Wed, 9 Apr 2014 11:24:16 -0400 From: Tom Lane To: Robert Haas cc: Heikki Linnakangas , Andrew Dunstan , Peter Geoghegan , "pgsql-hackers@postgresql.org" Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) In-reply-to: References: <27299.1396989666@sss.pgh.pa.us> <28589.1396992841@sss.pgh.pa.us> <29030.1396993582@sss.pgh.pa.us> <534475B7.6020908@dunslane.net> <5344EAA4.1050605@vmware.com> Comments: In-reply-to Robert Haas message dated "Wed, 09 Apr 2014 11:16:13 -0400" Date: Wed, 09 Apr 2014 11:24:16 -0400 Message-ID: <30137.1397057056@sss.pgh.pa.us> X-Pg-Spam-Score: -2.2 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas > 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