Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id 20201218195925.4qj6p2kxrvkdrmur@localhost
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting
List pgsql-hackers
> On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6@gmail.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.



pgsql-hackers by date:

Previous
From: Ryan Lambert
Date:
Subject: Re: WIP: System Versioned Temporal Table
Next
From: Першин Юрий Петрович
Date:
Subject: libpq @windows : leaked singlethread_lock makes AppVerifier unhappy