Re: [HACKERS] [PATCH] Generic type subscripting

> On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> > On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
> >> We can certainly reconsider the API for the parsing hook if there's
> >> really a good reason for these to be different types, but it seems
> >> like that would just be encouraging poor design.
>
> > To be more specific, this is the current behaviour (an example from the
> > tests) and it doesn't seem right:
>
> > =# update test_jsonb_subscript
> > set test_json['a'] = 3 where id = 1;
> > UPDATE 1
> > =# select jsonb_typeof(test_json->'a')
> > from test_jsonb_subscript where id = 1;
> > jsonb_typeof
> > --------------
> > string
>
>
> I'm rather inclined to think that the result of subscripting a
> jsonb (and therefore also the required source type for assignment)
> should be jsonb, not just text. In that case, something like
> update ... set jsoncol['a'] = 3
> would fail, because there's no cast from integer to jsonb. You'd
> have to write one of
> update ... set jsoncol['a'] = '3'
> update ... set jsoncol['a'] = '"3"'
> to clarify how you wanted the input to be interpreted.
> But that seems like a good thing, just as it is for jsonb_in.

Yep, that makes sense, will go with this idea.