pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
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: Sat, 25 Feb 2017 12:04:21 -0500
Message-ID: <12734.1488042261@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (39+ messages)  latest in thread

Message-ID: <12734.1488042261@sss.pgh.pa.us>
Permalink:  ../12734.1488042261@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/12734.1488042261@sss.pgh.pa.us

 · 

reply
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: <12734.1488042261@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