From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: btree_gin and btree_gist for enums
In-reply-to: <4376a7bf-ab8c-e640-9021-94b148f9d733@2ndQuadrant.com>
References: <56EA8A71.8060107@dunslane.net> <56EACB8C.1040406@dunslane.net>
 <CAE2gYzyB=vyquQ2hEWA9UwNb=zYAKFsNO5vBtbfkV2=PzoPZjg@mail.gmail.com>
 <03f7d748-0f89-e8e1-094d-f04e1026b93d@dunslane.net>
 <27220.1478360811@sss.pgh.pa.us>
 <e60f50c4-899a-d48a-6cb4-4611acf2f73c@dunslane.net>
 <31412.1478366009@sss.pgh.pa.us>
 <60fb708c-8b3c-1337-934e-c1bfe2afc539@dunslane.net>
 <db2b70a4-78d7-294a-a315-8e7f506c5978@2ndQuadrant.com>
 <8258.1487886101@sss.pgh.pa.us>
 <4376a7bf-ab8c-e640-9021-94b148f9d733@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Fri, 24 Feb 2017 09:48:30 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6703.1487952174.1@sss.pgh.pa.us>
Date: Fri, 24 Feb 2017 11:02:54 -0500
Message-ID: <6704.1487952174@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andrew Dunstan <andrew.dunstan@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.

> 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers