Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
Дата
Msg-id 5EE1519A-7DF7-4EB0-B7EA-5492F5F53C63@justatheory.com
обсуждение исходный текст
Ответ на Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 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.

The use of JSON will not be ideal -- not in this sense. For example, at $work, we’re using it in place of an EAV model.
Hencemost rows have the same keys (or a subset of known keys). Or think of your favorite JSON API: every call to
http://api.pgxn.org/user/$username.jsonis going to have a very similar structure. 

> 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?

Fixing++

David


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers