On 05/24/2015 05:38 PM, Tom Lane wrote:
Andres Freund <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
