Re: [HACKERS] [PATCH] Generic type subscripting
От | Dmitry Dolgov |
---|---|
Тема | Re: [HACKERS] [PATCH] Generic type subscripting |
Дата | |
Msg-id | 20201230134733.q5j2pcvwutnc76cs@localhost обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Generic type subscripting (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Generic type subscripting
|
Список | pgsql-hackers |
> On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote: > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote: > > > > In a case like jsonpath['...'], the initially UNKNOWN-type literal could > > in theory be coerced to any of these types, so you'd have to resolve that > > case manually. The overloaded-function code has an internal preference > > that makes it choose TEXT if it has a choice of TEXT or some other target > > type for an UNKNOWN input (cf parse_func.c starting about line 1150), but > > if you ask can_coerce_type() it's going to say TRUE for all three cases. > > > > Roughly speaking, then, I think what you want to do is > > > > 1. If input type is UNKNOWNOID, choose result type TEXT. > > > > 2. Otherwise, apply can_coerce_type() to see if the input type can be > > coerced to int4, text, or jsonpath. If it succeeds for none or more > > than one of these, throw error. Otherwise choose the single successful > > type. > > > > 3. Apply coerce_type() to coerce to the chosen result type. > > > > 4. At runtime, examine exprType() of the input to figure out what to do. > > Thanks, that was super useful. Following this suggestion I've made > necessary adjustments for the patch. There is no jsonpath support, but > this could be easily added on top. And the forgotten patch itself.
Вложения
В списке pgsql-hackers по дате отправления: