On 02/24/2017 11:02 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.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.
fair enough. Will do it that way. > >> 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. > > I'll go with CallerFInfoFunctionCall2 etc. In the btree_gist system the calls to the routines like enum_cmp are buried about three levels deep. I'm thinking I'll just pass the flinfo down the stack and just call these routines at the bottom level. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
