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: <fac3c5d1-ad66-3a15-c181-c7aadf1d6ad1@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>
 <6704.1487952174@sss.pgh.pa.us>
 <930cb563-6dc6-c4af-3be9-31f06c60361e@2ndQuadrant.com>
 <8a8c60b4-39c0-69a4-824c-e364f5fd97ea@2ndQuadrant.com>
 <fac3c5d1-ad66-3a15-c181-c7aadf1d6ad1@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Sat, 25 Feb 2017 11:51:48 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12733.1488042261.1@sss.pgh.pa.us>
Date: Sat, 25 Feb 2017 12:04:21 -0500
Message-ID: <12734.1488042261@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 02/24/2017 05:34 PM, Andrew Dunstan wrote:
>> It's occurred to me that we could reduce the code clutter in fmgr.c a
>> bit by turning the DirectFunctionCall{n]Coll functions into macros
>> calling these functions and passing NULL as the flinfo param.

> here's a patch along those lines. If there's agreement on this I can
> finish up the work on btree_gist and btree_gin supoport for enums.

I'm not really thrilled with doing it like that, for two reasons:

1. This makes it look like CallerFInfoFunctionCallN is the more basic,
common interface, which it isn't and never will be.  At best, that's
confusing.  And I don't like having only one documentation block
covering both interfaces; that does nothing for clarity either.

2. By my count there are over 500 uses of DirectFunctionCallN in the
backend.  This will add an additional hidden parameter to each one,
implying code bloat and some fractional speed cost.

I think it'd be better to leave DirectFunctionCallN alone and just invent
a small number of CallerFInfoFunctionCallN support functions (maybe N=1
and N=2 would be enough, at least for now).

			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