MIME-Version: 1.0
In-Reply-To: <29011.1399415977@sss.pgh.pa.us>
References: 
 <CAM3SWZQzOxmryVe_bdu9WhqbJTBoiqM7knvKm0oRYxvfsFnz7Q@mail.gmail.com>
 <534475B7.6020908@dunslane.net> <5344EAA4.1050605@vmware.com>
 <CA+TgmoZucoe-w5P_16A-gdfRBFCCu7PD17YO-KqrYPBhb5TxAA@mail.gmail.com>
 <30137.1397057056@sss.pgh.pa.us>
 <CAM-w4HNawF2sPDSUrZsng7zgGnste-Vy1+42AufyVq9UkVeCZw@mail.gmail.com>
 <20140422223230.GL10046@momjian.us>
 <16527.1398214220@sss.pgh.pa.us>
 <20140506201048.GI30817@momjian.us>
 <16769.1399407530@sss.pgh.pa.us>
 <20140506212020.GK30817@momjian.us>
 <57E8AA44-F816-45F2-BB61-5A854FFB0A97@justatheory.com>
 <28554.1399414853@sss.pgh.pa.us>
 <CAM3SWZS4Tn-xZOBqM_ds-nhB2wLSpKG86rcJnMSexqDJqWgzNg@mail.gmail.com>
 <29011.1399415977@sss.pgh.pa.us>
Date: Tue, 6 May 2014 16:01:16 -0700
Message-ID: 
 <CAM3SWZSA9jDae11p6wMxap9MiGD_C7X5JSjqiFSr-5NcKJb4Sw@mail.gmail.com>
Subject: Re: default opclass for jsonb (was Re: Call for
 GIST/GIN/SP-GIST opclass documentation)
From: Peter Geoghegan <pg@heroku.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David E. Wheeler" <david@justatheory.com>,
 Bruce Momjian <bruce@momjian.us>, Greg Stark <stark@mit.edu>,
 Robert Haas <robertmhaas@gmail.com>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Tue, May 6, 2014 at 3:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Meh.  I would not think that that represents effective use of JSON:
> if the rows are all the same, why aren't you exposing that structure
> as regular SQL columns?  IMHO, the value of JSON fields within a SQL
> table is to deal with data that is not so well structured.

I used to think that. That actually isn't what people want from a JSON
type, though. People want a flexible data model, but they still
realize that if within a table/"collection" everything is totally
heterogeneous, it becomes impossible to effectively query. They don't
want to run migrations. Or, maybe they are consuming JSON from a
third-party API, and have no control over the schema, even though it
is really is a schema (already represented as JSON, making jsonb a
compelling representation) -- that's a very common use case. It's much
more compelling to store semi-structured data as JSON. Totally
unstructured data just isn't that interesting.

Don't take my word for it, though. See
http://docs.mongodb.org/manual/data-modeling, for example. There is an
implicit assumption throughout that most documents within a MongoDB
collection have the same keys. The choice to not separately index keys
in the GIN hash opclass is far from arbitrary, even if you don't agree
with it.

> In any case, it was certainly the complaint that insertions might
> fail altogether that made me (and I assume others) want to not have
> jsonb_ops as the default opclass.  Is there a good reason not to
> fix that limitation while we still can?

I have no objection to either changing the default, or having no default.

-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers