From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: btree_gin and btree_gist for enums |
Date: | 2017-02-24 16:02:54 |
Message-ID: | 6704.1487952174@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 02/23/2017 04:41 PM, Tom Lane wrote:
>> The reason this is kind of scary is that it's just blithely assuming
>> that the function won't look at the *other* fields of the FmgrInfo.
>> If it did, it would likely get very confused, since those fields
>> would be describing the GIN support function, not the function we're
>> calling.
>>
>> We could alternatively have this trampoline function set up a fresh, local
>> FmgrInfo struct that it zeroes except for copying fn_extra and fn_mcxt
>> from the caller's struct, and then it copies fn_extra back again on the
>> way out. That's a few more cycles but it would be safer, I think; if the
>> function tried to look at the other fields such as fn_oid it would see
>> obviously bogus data.
> Do we want one or both of these? I'm prepared to code up a patch to
> fmgr.[ch] to provide them.
On reflection I'm not sure that the double-copy approach is all that much
safer than just passing down the caller's flinfo pointer. Most of the
time it would be better, but suppose that the callee updates fn_extra
and then throws elog(ERROR) --- the outcome would be different, probably
creating a leak in fn_mcxt. Maybe this would still be okay, because
perhaps that FmgrInfo is never used again, but I don't think we can assume
that for the case at hand.
At this point I'd be inclined to just document that the called function
should only use fn_extra/fn_mcxt.
> I don't know what to call it either. In my test I used
> CallerContextFunctionCall2 - not sure if that's quite right, but should
> be close.
CallerInfo? CallerFInfo? Or we could spell out CallerFmgrInfo but
that seems a bit verbose.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-24 16:17:05 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Tom Lane | 2017-02-24 15:54:29 | Re: safer node casting |