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 по дате отправления: