On Tue, May 6, 2014 at 3:39 PM, Tom Lane <t...@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