Re: nested hstore patch

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: nested hstore patch
Дата
Msg-id 507BA028-0290-4B0E-A1A0-FB6A97FBC95A@excoventures.com
обсуждение исходный текст
Ответ на Re: nested hstore patch  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Dec 23, 2013, at 6:28 AM, Robert Haas wrote:

> On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler <david@justatheory.com> wrote:
>> * New operators:
>>  + `hstore -> int`:     Get string value at array index (starting at 0)
>>  + `hstore ^> text`:    Get numeric value for key
>>  + `hstore ^> int`:     Get numeric value at array index
>>  + `hstore ?> text`:    Get boolean value for key
>>  + `hstore ?> int`:     Get boolean value at array index
>>  + `hstore #> text[]`:  Get string value for key path
>>  + `hstore #^> text[]`: Get numeric value for key path
>>  + `hstore #?> text[]`: Get boolean value for key path
>>  + `hstore %> text`:    Get hstore value for key
>>  + `hstore %> int`:     Get hstore value at array index
>>  + `hstore #%> text[]`: Get hstore value for key path
>>  + `hstore ? int`:      Does hstore contain array index
>>  + `hstore #? text[]`:  Does hstore contain key path
>>  + `hstore - int`:      Delete index from left operand
>>  + `hstore #- text[]`:  Delete key path from left operand
>
> Although in some ways there's a certain elegance to this, it also
> sorta looks like punctuation soup.  I can't help wondering whether
> we'd be better off sticking to function names.

The key thing is making it easy for people to easily chain calls to their nested hstore objects, and I think these
operatorsaccomplish that. 

Some of them are fairly intuitive, and I think as a community if we have a) good docs, b)  good blog posts on how to
usenested hstore, and c) provides clear instructions @ PG events on how to use it, it would be okay, though some
things,i.e. extracting the key by a path, might be better being in a function anyway.  However, having it as an
operatormight encourage more usage, only because people tend to think that "functions will slow my query down." 

My only concern is the consistency with the generally accepted standard of JSON and with the upcoming jsonb type.   I'm
notsure if the jsonb API has  been defined yet, but it would be great to keep consistency between nested hstore and
jsonbso people don't have to learn two different access systems.  Data extraction from JSON is often done by the dot
operatorin implementations, and depending on the language you are in, there are ways to add / test existence / remove
objectsfrom the JSON blob. 

Being able to extract objects from nested hstore / JSON using the dot operator would be simple and intuitive and
generalwell-understood, but of course there are challenges with doing that in PG and well, proper SQL. 

Jonathan


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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: preserving forensic information when we freeze