Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35]) by postgresql.org (Postfix) with ESMTP id BB535475D77 for ; Mon, 15 Apr 2002 23:57:37 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id g3G3vKi06010; Mon, 15 Apr 2002 23:57:20 -0400 (EDT) From: Bruce Momjian Message-Id: <200204160357.g3G3vKi06010@candle.pha.pa.us> Subject: Re: [SQL] 16 parameter limit In-Reply-To: <20020415235216.5bdf393a.nconway@klamath.dyndns.org> To: Neil Conway Date: Mon, 15 Apr 2002 23:57:20 -0400 (EDT) Cc: Christopher Kings-Lynne , peter_e@gmx.net, tgl@sss.pgh.pa.us, josh@agliodbs.com, jproctor@prium.net, pgsql-patches@postgresql.org X-Mailer: ELM [version 2.4ME+ PL97 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200204/163 X-Sequence-Number: 3678 Neil Conway wrote: > On Tue, 16 Apr 2002 11:35:57 +0800 > "Christopher Kings-Lynne" wrote: > > > > Are we staying at 16 as the default? I personally think we can > > > > increase it to 32 with little penalty, > > > > > > If you want to increase it, let's just increase it and not add any more > > > configure options. If someone wants more than 32 then we really need to > > > start talking about design issues. > > > > Why not give them the configure option? It's not good HCI to impose > > arbitrary limits on people...? > > It's not an arbitrary limit -- users can easily change pg_config.h. Let me just point out that you have to change pg_config.h.in and run configure _or_ change pg_config.h and _never_ run configure again. It is this complexity that makes a configure option look acceptable. Maybe we should pull some of the hard-coded, non-configure stuff from pg_config.h into a separate file and just include it from pg_config.h. > > We can default it to 32, since there's demand for it. If a particular user > > decided to configure it higher, then they do that knowing that it may cause > > performance degradation. It's good to give them that choice though. > > What if someone actually uses functions with more than 32 > arguments? Their code will not longer be portable among > PostgreSQL installations, and they'll need to get the local > admin to recompile. It is usually C++ overloading functions that use lots of args, or functions that pass every table column into the function. In those cases, I can easily see 32 params. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026