Re: jsonb concatenate operator's semantics seem questionable

On 05/24/2015 05:38 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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