Re: json api WIP patch - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: json api WIP patch
Date
Msg-id 51104775.9080106@krosing.net
Whole thread Raw
In response to Re: json api WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json api WIP patch  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 01/31/2013 11:20 PM, Andrew Dunstan wrote:
>
> I'm happy to take opinions about this, and I expected
> some bikeshedding, but your reaction is contrary to
> everything others have told me. Mostly they love the operators.
What I would really like is if we extended postgresql core and made
a few more constructs definable as overloadable operator:

1) array / dictionary element lookup  a[b] CREATE OPERATOR [] (...)

2) attribute lookup  a.b CREATE OPERATOR . (...)

then you could make json lookups either step-by-step using

CREATE OPERATOR [] (    PROCEDURE = json_array_lookup, LEFTARG = json, RIGHTARG = int)

and

CREATE OPERATOR [] (    PROCEDURE = json_dict_lookup, LEFTARG = json, RIGHTARG = text)

fourthname = myjson[4]['name']


or perhaps a single


CREATE OPERATOR [] (    PROCEDURE = json_deep_lookup, LEFTARG = json, RIGHTARG = VARIADIC 
"any")

fourthname = myjson[4, 'name']


though I suspect that we do not support type VARIADIC "any" in operator 
definitions

---------
Hannu



> I guess that '~>' and '~>>' would work as well as '->' and '->>'.
>
>
> cheers
>
> andrew
>
>




pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: get_progname() should not be const char *?
Next
From: Andres Freund
Date:
Subject: Re: split rm_name and rm_desc out of rmgr.c