Skip site navigation (1) Skip section navigation (2)

Re: [SQL] 16 parameter limit

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>,John Proctor <jproctor(at)prium(dot)net>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [SQL] 16 parameter limit
Date: 2002-04-16 02:58:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patchespgsql-sql
The following patch adds --maxindfuncparams to configure to allow you to
more easily set the maximum number of function parameters and columns
in an index.  (Can someone come up with a better name?)

The patch also removes --def_maxbackends, which Tom reported a few weeks
ago he wanted to remove.  Can people review this?  To test it, you have
to run autoconf.

Are we staying at 16 as the default?   I personally think we can
increase it to 32 with little penalty, and that we should increase


Tom Lane wrote:
> "Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> > Personally, as a heavy user of PL/pgSQL procedures, I'm not sure you
> >  need to increase the *default* number of parameters.  Postgres just
> >  needs to implement a parameter number change as part of a documented
> >  command-line compile-time option, i.e. "--with-parameters=32".
> I would not object to providing such a configure option; it seems a
> reasonable thing to do.  But the real debate here seems to be what
> the default should be.  The ACS people would like their code to run
> on a "stock" Postgres installation, so they've been lobbying to change
> the default, not just to make it fractionally easier to build a
> non-default configuration.
> > Also, what is the practical maximum number of parameters?
> If you tried to make it more than perhaps 500, you'd start to see
> index-tuple-too-big failures in the pg_proc indexes.  Realistically,
> though, I can't see people calling procedures with hundreds of
> positionally-specified parameters --- such code would be unmanageably
> error-prone.
> I was surprised that people were dissatisfied with 16 (it was 8 not very
> long ago...).  Needing more strikes me as a symptom of either bad coding
> practices or missing features of other sorts.
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-04-16 02:59:19
Subject: Re: Stumbled upon a time bug...
Previous:From: Christopher Kings-LynneDate: 2002-04-16 02:58:13
Subject: Re: RFC: Generating useful names for foreign keys and checks

pgsql-patches by date

Next:From: Hiroshi InoueDate: 2002-04-16 03:18:16
Subject: Re: ANSI Compliant Inserts
Previous:From: Bruce MomjianDate: 2002-04-16 02:46:23
Subject: Re: ANSI Compliant Inserts

pgsql-sql by date

Next:From: Rod TaylorDate: 2002-04-16 03:19:45
Subject: Re: [PATCHES] [SQL] 16 parameter limit
Previous:From: Josh BerkusDate: 2002-04-16 02:51:11
Subject: Re: please advise on column data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group