Re: [HACKERS] [PATCH] Generic type subscripting
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] [PATCH] Generic type subscripting |
Дата | |
Msg-id | CAFj8pRASZBi2jv8QA6EvVGmhN6WzVz6tqMfW6nvRDd=UV1CxBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Generic type subscripting (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] Generic type subscripting
|
Список | pgsql-hackers |
čt 17. 12. 2020 v 19:49 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Dmitry Dolgov <9erthalion6@gmail.com> writes:
> While rebasing the jsonb patch I found out that the current subscripting
> assignment implementation in transformAssignmentIndirection always
> coerce the value to be assigned to the type which subscripting result
> suppose to have (refrestype). For arrays it's fine, since those two
> indeed must be the same, but for jsonb (and for hstore I guess too) the
> result of subscripting is always jsonb (well, text type) and the
> assigned value could be of some other type. This leads to assigning
> everything converted to text.
So ... what's the problem with that? Seems like what you should put
in and what you should get out should be the same type.
I don't think so. For XML or JSON the target can be different, and it can safe one CAST
DECLARE
n int;
v varchar;
js jsonb default '{"n": 100, "v" : "Hello"};
BEGIN
n := js['n'];
v := js['v'];
Can be nice to do this with a minimum number of transformations.
Regards
Pavel
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: