Re: nested hstore patch

On 12/23/2013 12:28 PM, 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.
>
Has anybody looked into how hard it would be to add "method" notation
to postgreSQL, so that instead of calling

getString(hstorevalue, n)

we could use

hstorevalue.getString(n)

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ