Re: jsonb and nested hstore

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: jsonb and nested hstore
Дата
Msg-id CAHyXU0wPLyxywG7J38dGVA=7xPj=+D8kXJmZ=XR7OHEGjN6m_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: jsonb and nested hstore  (Stephen Frost <sfrost@snowman.net>)
Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>>>> *All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it as a
> *separate* extension; it'd have to be included in the hstore extension.

I disagree with that.  The shared C bits can live inside the core
system and the SQL level hooks and extension specific behaviors could
live in an extension.  AFAICT moving jsonb to extension is mostly a
function of migrating the hard coded SQL hooks out to an extension
(I'm probably oversimplifying though).

> Just out of curiosity, exactly what features are missing from jsonb
> today that are available with hstore?  How long would it take to
> copy-and-paste all that code, if someone were to decide to do the
> work instead of argue about it?

Basically opclasses, operators (particularly search operators) and
functions/operators to manipulate the hstore in place.  Personally I'm
not inclined to copy/paste the code.  I'd also like to see this stuff
committed, and don't want to hold up the patch for that unless it's
determined for other reasons (and by other people) this is the only
reasonable path for 9.4.

merlin



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: jsonb and nested hstore