get_fn_expr_argtype() vs. internal calls

From: Noah Misch <noah(at)leadboat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: get_fn_expr_argtype() vs. internal calls
Date: 2011-12-29 21:17:11
Message-ID: 20111229211711.GA8085@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-12-29 22:06:15 Re: failed regress test
Previous Message Peter Eisentraut 2011-12-29 21:02:34 ALTER DOMAIN DROP CONSTRAINT doesn't catch errors