get_fn_expr_argtype() vs. internal calls
| От | Noah Misch |
|---|---|
| Тема | get_fn_expr_argtype() vs. internal calls |
| Дата | |
| Msg-id | 20111229211711.GA8085@tornado.leadboat.com обсуждение исходный текст |
| Ответы |
Re: get_fn_expr_argtype() vs. internal calls
|
| Список | pgsql-hackers |
We document that a polymorphic C-language function may identify the concrete
data type of each argument using calls to get_fn_expr_argtype(). That relies
on FmgrInfo.fn_expr, which only the executor sets. Calls of internal origin,
by way of {Direct,,Oid}FunctionCall*(), don't cons up an fn_expr, so
get_fn_expr_argtype() just returns InvalidOid every time. (Indeed, we
couldn't easily do better in many cases.) To what extent is it safe to rely
on this situation remaining as it is?
I ask on account of some second thoughts I had about CheckIndexCompatible().
When writing it, I did not explicitly consider operator classes having
polymorphic opcintype. If get_fn_expr_argtype() were to work in a function
called from the btree search code, CheckIndexCompatible() should impose
stricter checks on indexes having opclasses of polymorphic opcintype. If
that's not too likely to happen, I might just add a comment instead.
Thanks,
nm
В списке pgsql-hackers по дате отправления: