Re: Extract numeric filed in JSONB more effectively
| От | Andy Fan |
|---|---|
| Тема | Re: Extract numeric filed in JSONB more effectively |
| Дата | |
| Msg-id | CAKU4AWr1bsGaWWzQHJwB=WXboJrCM242=x6XbHO06vuhWsY4Ww@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Extract numeric filed in JSONB more effectively (Chapman Flack <chap@anastigmatix.net>) |
| Ответы |
Re: Extract numeric filed in JSONB more effectively
|
| Список | pgsql-hackers |
Hi Chapman,
Thanks for the review!
The idea of an 'internal' return type with no 'internal' parameter
was quickly and rightly shot down.
Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:
anyelement fn(anyment in);
if the exprType(in) in the query tree is X, then PG would think fn
return type X. that's why we have to have an anyelement in the
input.
But it would have seemed to me
enough to address that objection by using 'internal' also in its
parameter list. I could imagine a function declared with two
'internal' parameters, one understood to be a JsonbValue and one
understood to be a type oid, and an 'internal' result, treated in
the rewritten expression tree as binary-coercible to the desired
result.
I have some trouble understanding this. are you saying something
like:
internal fn(internal jsonValue, internal typeOid)?
If so, would it break the type-safety system? And I'm not pretty
sure the 'binary-coercible' here. is it same as the 'binary-coercible'
in "timestamp is not binary coercible with timestamptz since..."?
I have a strong feeling that I think I misunderstood you here.
Perhaps there are parts of that rewriting that no existing node type
can represent?
I didn't understand this as well:(:(
But I have the sense that that approach was abandoned early, in
favor of the current approach using user-visible polymorphic
types, and supplying typed dummy constants for use in the
resolution of those types, with a new function introduced to create
said dummy constants, including allocation and input conversion
in the case of numeric, just so said dummy constants can be
passed into functions that have no use for them other than to
call get_fn_expr_argtype to recover the type oid, which was the
only thing needed in the first place.
Yes, but if we follow the type-safety system, we can't simply input
a Oid targetOid, then there are some more considerations here:
a). we can't use the makeNullConst because jsonb_xxx_type is
strict, so if we have NULL constant input here, the PG system
will return NULL directly. b). Not only the type oid is the thing
We are interested in the const.constvalue is as well since
'explain select xxxx' to access it to show it as a string.
Datum(0) as the constvalue will crash in this sense. That's why
makeDummyConst was introduced.
something like "assertion of
'internal'-to-foo binary coercibility, vouched by a prosupport
function", would that be a bad thing?
I can't follow this as well. Could you provide the function prototype
here?
Best Regards
Andy Fan
В списке pgsql-hackers по дате отправления: