Forum OpenACS Development: PostgreSQL 7.1 functions can take more than 16 parameters

1: PostgreSQL 7.1 functions can take more than 16 parameters

Posted by Roberto Mello on 07/11/01 03:11 AM

Did anyone here know that PG 7.1 functions can take more than 16 parameters? I just saw this in the pgsql-sql list. It's a compile-time parameter, set in src/include/config.h's FUNC_MAX_ARGS. The comments say this:

/*
 * 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.
 *
 * CAUTION: changing these requires an initdb.
 *
 * BTW: if you need to call dynamically-loaded old-style C functions 
that
 * have more than 16 arguments, you will also need to add cases to the
 * switch statement in fmgr_oldstyle() in 
src/backend/utils/fmgr/fmgr.c.
 * But consider converting such functions to new-style instead...
 */
#define INDEX_MAX_KEYS      16
#define FUNC_MAX_ARGS       INDEX_MAX_KEYS

This same parameter controls how many columns are allowed in an index.

I'd like to investigate this further, as there are obvious benefits to some packages. Does anyone know if there are any drawbacks to increasing this value?

If there aren't, then maybe we could ask the PG team to have the default set to something more than 16?

Thoughts?

2: Response to PostgreSQL 7.1 functions can take more than 16 parameters (response to 1)

Posted by Don Baccus on 07/11/01 10:21 AM

Well...sorry, been there, done that. Asking the PG group to increase the default value was on the first list of stuff Ben and I put together for OpenACS 4.x when we met in aD's offices to discuss this project many, many months ago.

The default in PG hasn't changed, as you can see.

As far as asking folks to change it and compile their own PG, we did that in PG 6.5 and 7.0 in order to get blksize - and therefore maxiumum bboard post lengths etc - up to a reasonable figure.

But that's not necessary in PG 7.1, and we're now seeing more work in the way of pre-canned distributions with default values being installed on users machines. I think the argument against forcing a recompile for folks to use OpenACS has grown, not shrunk, since our first 3.x release.

It's unfortunate. I personally have a hard time believing that increasing the default value to 32 params/max colums to index would cause serious user problems in today's world of big PC's being sold for relatively small amounts of money.

But thus far the PG folk don't see it this way. Ironically, 16
parameters would've been considered to be extremely generous and forward-looking a few years ago, i.e. when it was chosen ...

3: Response to PostgreSQL 7.1 functions can take more than 16 parameters (response to 1)

Posted by Jonathan Marsden on 07/12/01 03:27 PM

I'm with Don. It's unfortunate, but the benefits to OpenACS 4.x porters of making such a change would be more than offset by the pain for OpenACS installers, who would need to recompile PG and then do an initdb using the modified version. There will hopefully be a lot more
OpenACS 4.x installers than porters...

Given the interest in "better out of box experience" in recent posts, forcing a PG recompile looks like a step in the wrong direction.

Is it worth re-asking the PG folks about this, ready for PG 7.2 or 7.3 or whatever ... so at least it could get onto their agenda for some (distant?) future PG version? In the 'many months' since it apparently first came up, hardware has got still faster and still cheaper, so maybe the case is now sufficiently strong?

4: Response to PostgreSQL 7.1 functions can take more than 16 parameters (response to 1)

Posted by Roberto Mello on 07/12/01 04:32 PM

That's a bummer Don. Maybe if the community keeps pinging the PG team we can get it.

I noticed that the %TYPE patch for PL/pgSQL was included in 7.2 because of community pressure (on which we played a role) and because the patch was good too, of course.

I wasn't proposing asking folks to compile custom-versions. That'd require an initdb and all. So I agree with Jonathan and you too.