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
Date: Thu, 23 Feb 2017 16:41:41 -0500
Message-ID: <8258.1487886101@sss.pgh.pa.us> (raw)
In-Reply-To: <db2b70a4-78d7-294a-a315-8e7f506c5978@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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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.
BTW, while I'm looking at this ... isn't gin_enum_cmp broken on its face?
It's using DirectFunctionCall2 to call enum_cmp, and that's wrong because
DirectFunctionCall2 does not pass through a flinfo but enum_cmp needs to
have one. I've not tested, but I'm certain that this would dump core if
asked to compare odd-numbered enum OIDs.
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
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: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com
Subject: Re: btree_gin and btree_gist for enums
In-Reply-To: <8258.1487886101@sss.pgh.pa.us>
* 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