On 05/24/2015 05:38 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote:
>>> Having gone to the trouble of making the parser support this stuff (in
>>> a way that makes us not follow the SQL standard in a couple of
>>> places), we ought to have a similar capability for jsonb. I haven't
>>> looked into it, but it seems like a good project for 9.6. I'm not
>>> volunteering to undertake the project, though.
>> I'm not convinced. The array stuff requires ugly contortions in a bunch
>> of places, and it's likely going to be worse for jsonb.
> FWIW, I've got some interest myself in the idea of allowing subscripting
> syntax to be applied to things other than plain arrays, which I think is
> what Peter is proposing here. You could imagine applying it to hstore,
> for example, and ending up with something that acts like a Perl hash
> (and even performs similarly, once you'd invented an expanded-object
> representation for hstore). Coming up with a non-ugly API for datatypes
> would be the hard part.
>
>
Interesting, you do cast a wide net these days.
I imagine we'd have each type register a function along the lines of
foo_set(target foo, newval element_of_foo, path variadic "any") returns boolean
And then we'd turn
set myfoo[bar][baz][blurfl] = someval
into
foo_set(myfoo, someval, bar, baz, blurfl)
In the catalog I guess we'd need to store the oid of the function, and
possibly oid of the element type (e.g. for jsonb it would just be
jsonb), and some dependency information.
But I'm sure there a a great many wrinkles I haven't thought of.
cheers
andrew