Re: jsonb and nested hstore

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: jsonb and nested hstore
Дата
Msg-id CAHyXU0xz1L8KzWJoDHoKX6AhZ0DX3v0DHbUMMsyeumgfCvEA1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: jsonb and nested hstore  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: jsonb and nested hstore  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Fri, Jan 31, 2014 at 9:26 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 01/31/2014 09:53 AM, Merlin Moncure wrote:
>>
>> On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan <andrew@dunslane.net>
>> wrote:
>>>
>>> On 01/31/2014 08:57 AM, Merlin Moncure wrote:
>>>>
>>>> On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov <obartunov@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hmm,
>>>>> neither me, nor Teodor have experience and knowledge with
>>>>> populate_record() and moreover hstore here is virgin and we don't know
>>>>> the right behaviour, so I think we better take it from jsonb, once
>>>>> Andrew realize it. Andrew ?
>>>>
>>>> Andrew Gierth wrote the current implementation of htsore
>>>> populate_record IIRC.  Unfortunately the plan for jsonb was to borrow
>>>> hstore's (I don't think hstore can use the jsonb implementation
>>>> because you'd be taking away the ability to handle internally nested
>>>> structures it currently has).  Of my two complaints upthread, the
>>>> second one, not being able to populate from and internally well formed
>>>> structure, is by far the more serious one I think.
>>>>
>>>
>>> Umm, I think at least one of us is seriously confused.
>>>
>>> I am going to look at dealing with these issues in a way that can be used
>>> by
>>> both - at least the populate_record case.
>>>
>>> As far as populate_record goes, there is a bit of an impedance mismatch,
>>> since json/hstore records are heterogenous and one-dimensional, whereas
>>> sql
>>> arrays are homogeneous and multidimensional. Right now I am thinking I
>>> will
>>> deal with arrays up to two dimensions, because I can do that relatively
>>> simply, and after that throw in the towel. That will surely deal with
>>> 99.9%
>>> of use cases. Of course this would be documented.
>>>
>>> Anyway, Let me see what I can do.
>>>
>>> If Andrew Gierth wants to have a look at fixing the hstore() side that
>>> might
>>> help speed things up.
>>
>> (ah, you beat me to it.)
>>
>> Disregard my statements above. It works.
>>
>> postgres=# select jsonb_populate_record(null::x, hstore(row(1,
>> array[row(1, array[row(1, array[1,2])::z])::y])::x)::jsonb);
>>                                  jsonb_populate_record
>>
>> -------------------------------------------------------------------------------------
>>
>> (1,"{""(1,\\""{\\""\\""(1,\\\\\\\\\\""\\""{1,2}\\\\\\\\\\""\\"")\\""\\""}\\"")""}")
>
>
> Actually, there is a workaround to the limitations of hstore(record):

yeah I'm ok with hstore() function as it is.  That also eliminates
backwards compatibility concerns so things worked out.  The only 'must
fix' 9.4 facing issue I see on the table is to make sure jsonb
populate function is forward compatible with future expectations of
behavior which to me means zeroing in on the necessity of the as_text
argument (but if you can expand coverage without jeopardizing 9.4
inclusion than great...).

For my part I'm going to continue functionally testing the rest of the
API (so far, a cursory look hasn't turned up anything else).  I'm also
signing up for some documentation refinements which will be done after
you nail down these little bits but before the end of the 'fest.

IMNSHO, formal code review needs to begin ASAP (salahaldin is the
reviewer per the fest wiki)

merlin



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Recovery inconsistencies, standby much larger than primary