Re: [HACKERS] [PATCH] Generic type subscripting

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [HACKERS] [PATCH] Generic type subscripting
Дата
Msg-id 20201218195925.4qj6p2kxrvkdrmur@localhost
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Generic type subscripting  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] [PATCH] Generic type subscripting  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Ryan Lambert
Дата:
Сообщение: Re: WIP: System Versioned Temporal Table
Следующее
От: Першин Юрий Петрович
Дата:
Сообщение: libpq @windows : leaked singlethread_lock makes AppVerifier unhappy