Skip site navigation (1) Skip section navigation (2)

Re: get_fn_expr_argtype() vs. internal calls

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: get_fn_expr_argtype() vs. internal calls
Date: 2012-01-27 18:01:44
Message-ID: CA+TgmobN2+gVbMxXZO3KckxdNMw0Z1CsPcGE5Nwzy_ViATxOVw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-27 18:18:51
Subject: Re: Unreliable "pg_ctl -w start" again
Previous:From: Robert HaasDate: 2012-01-27 17:56:19
Subject: Re: Confusing EXPLAIN output in case of inherited tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group