public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Geoghegan <[email protected]>
To: Tom Lane <[email protected]>
Cc: David E. Wheeler <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
Date: Tue, 6 May 2014 16:01:16 -0700
Message-ID: <CAM3SWZSA9jDae11p6wMxap9MiGD_C7X5JSjqiFSr-5NcKJb4Sw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAM3SWZQzOxmryVe_bdu9WhqbJTBoiqM7knvKm0oRYxvfsFnz7Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoZucoe-w5P_16A-gdfRBFCCu7PD17YO-KqrYPBhb5TxAA@mail.gmail.com>
<[email protected]>
<CAM-w4HNawF2sPDSUrZsng7zgGnste-Vy1+42AufyVq9UkVeCZw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAM3SWZS4Tn-xZOBqM_ds-nhB2wLSpKG86rcJnMSexqDJqWgzNg@mail.gmail.com>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On Tue, May 6, 2014 at 3:39 PM, Tom Lane <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (65+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
In-Reply-To: <CAM3SWZSA9jDae11p6wMxap9MiGD_C7X5JSjqiFSr-5NcKJb4Sw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox