From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: btree_gin and btree_gist for enums
Date: Fri, 24 Feb 2017 09:48:30 -0500
Message-ID: <4376a7bf-ab8c-e640-9021-94b148f9d733@2ndQuadrant.com> (raw)
In-Reply-To: <8258.1487886101@sss.pgh.pa.us>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 02/23/2017 04:41 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> I'm not entirely sure how I should replace those DirectFunctionCall2 calls.
> Basically what we want is for the called function to be able to use the
> fcinfo->flinfo->fn_extra and fcinfo->flinfo->fn_mcxt fields of the
> FmgrInfo struct that GIN has set up for the btree_gin support function.
>
> The fast but somewhat scary way to do it would just be to pass through
> the flinfo pointer as-is. Imagine that fmgr.c grows a set of functions
> like
>
> Datum
> DontKnowWhatToCallThisFunctionCall2(PGFunction func,
> FmgrInfo *flinfo, Oid collation,
> Datum arg1, Datum arg2)
> {
> FunctionCallInfoData fcinfo;
> Datum result;
>
> InitFunctionCallInfoData(fcinfo, flinfo, 2, collation, NULL, NULL);
>
> fcinfo.arg[0] = arg1;
> fcinfo.arg[1] = arg2;
> fcinfo.argnull[0] = false;
> fcinfo.argnull[1] = false;
>
> result = (*func) (&fcinfo);
>
> /* Check for null result, since caller is clearly not expecting one */
> if (fcinfo.isnull)
> elog(ERROR, "function %p returned NULL", (void *) func);
>
> return result;
> }
>
> and then you'd just pass through the fcinfo->flinfo you got.
>
> 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.
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.
The technique is somewhat similar to what we do in plperl.c where we
fake up a function call for handling DO blocks.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andrew.dunstan@2ndquadrant.com, tgl@sss.pgh.pa.us
Subject: Re: btree_gin and btree_gist for enums
In-Reply-To: <4376a7bf-ab8c-e640-9021-94b148f9d733@2ndQuadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox