Re: Functions with more than 32 parameters - Mailing list pgsql-general

From Christopher Browne
Subject Re: Functions with more than 32 parameters
Date
Msg-id m3is50sfo2.fsf@knuth.knuth.cbbrowne.com
Whole thread Raw
In response to Understanding EXPLAIN ANALYZE output  ("Ed L." <pgsql@bluepolka.net>)
List pgsql-general
Centuries ago, Nostradamus foresaw when me@oisinglynn.com ("Oisin Glynn") would write:
> I am trying to keep database access encapsulated in functions from an
> insert and update point of view so as all of the applications writing
> to the database are using the same functions/statements.
>
> My problem is I was creating functions to do inserts/updates and now I
> have a table with more than 32 columns and the functions seem to only
> want to have 32 parameters?
>
> Is there any way around this?
>
> I have used stored procedures in this way with Oracle/SQL server
> before.  Or is there another strategy I could use?
>
> I am using Windows 2000 Postgres 8.0.1 if it makes a difference

Certainly you can change this.

Edit the following file in your source tree:

cbbrowne@wolfe:/brownes/wolfe/compiles/pgsql> vi src/include/pg_config_manual.h

/*
 * Maximum number of columns in an index and maximum number of
 * arguments to a function. They must be the same value.
 *
 * The minimum value is 8 (index creation uses 8-argument functions).
 * There is no specific upper limit, although large values will waste
 * system-table space and processing time.
 *
 * Changing these requires an initdb.
 */
#define INDEX_MAX_KEYS          32
#define FUNC_MAX_ARGS           INDEX_MAX_KEYS

You will have to recompile PostgreSQL and create a fresh database
instance using initdb with the new maxima for these configuration
values.

Fortunately, the ability to recompile as needed is one of the most
important points of this "open source" stuff...
--
"cbbrowne","@","gmail.com"
http://linuxdatabases.info/~cbbrowne/spreadsheets.html
They are  called  computers  simply  because computation  is  the only
significant job that has so far been given to them.  -- Louis Ridenour

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: postgres server failure during some database opearion
Next
From: Tom Lane
Date:
Subject: Re: a SELECT FOR UPDATE question