Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP id 325D2474E42
	for <pgsql-hackers@postgresql.org>;
	Tue, 16 Apr 2002 01:02:36 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3G51XF09409;
	Tue, 16 Apr 2002 01:01:34 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Neil Conway <nconway@klamath.dyndns.org>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	Bruce Momjian <pgman@candle.pha.pa.us>, josh@agliodbs.com,
	jproctor@prium.net, PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] [SQL] 16 parameter limit 
In-reply-to: <Pine.LNX.4.30.0204160032190.834-100000@peter.localdomain> 
References: <Pine.LNX.4.30.0204160032190.834-100000@peter.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Tue, 16 Apr 2002 00:36:11 -0400"
Date: Tue, 16 Apr 2002 01:01:33 -0400
Message-ID: <9406.1018933293@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200204/777
X-Sequence-Number: 21441

Peter Eisentraut <peter_e@gmx.net> writes:
> How about this:  We store the first 16 parameters in some fixed array for
> fast access like now, and when you have more than 16 then 17 and beyond
> get stored in some variable array in pg_proc.

<<itch>>  What's this going to cost us in the function lookup code paths?

If we can do it with little or no performance cost (at least for the
"normal case" of fewer-than-N parameters) then I'm all ears.

			regards, tom lane