get_fn_expr_argtype() vs. internal calls

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

On Thu, Dec 29, 2011 at 4:17 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> 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.

[ found this while reviewing emails I hadn't read carefully enough
when they were first posted ]

I think the way you actually chose to tighten this up is probably
safer, and it seems to have minimal downside.

Thanks for pursuing this despite the lack of response to your initial query.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company