get_fn_expr_argtype() vs. internal calls - Mailing list pgsql-hackers

From Noah Misch
Subject get_fn_expr_argtype() vs. internal calls
Date
Msg-id 20111229211711.GA8085@tornado.leadboat.com
Whole thread Raw
Responses Re: get_fn_expr_argtype() vs. internal calls  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: ALTER DOMAIN DROP CONSTRAINT doesn't catch errors
Next
From: Tom Lane
Date:
Subject: Re: failed regress test