Thread: Function Parameters

Function Parameters

From
"Oluwatope Akinniyi"
Date:
Hi,

Compliments of the season.

I tried to create a function with about 60 input parameters and got an
error message that a function cannot take more than 32 parameters.

Is there a way around this? Or Am I in error?

Best regards.

Tope


--


Re: Function Parameters

From
Michael Fuhr
Date:
On Sun, Jan 02, 2005 at 01:31:22AM +0000, Oluwatope Akinniyi wrote:

> I tried to create a function with about 60 input parameters and got an
> error message that a function cannot take more than 32 parameters.

What's the function's purpose?  Why does it need so many arguments?
You might be able to get around the limitation with a composite
type, but maybe there's a different way to do what you want.

Another possibility would be to rebuild PostgreSQL and change the
limit.  I don't know what the implications are other than what the
comment in the code says: "There is no specific upper limit, although
large values will waste system-table space and processing time" and
"Changing these requires an initdb."

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Re: Function Parameters

From
Pierre-Frédéric Caillaud
Date:
    Maybe you could use arrays as some function parameters ?

    Can you explain why you need so many parameters ?

On Sat, 1 Jan 2005 22:25:02 -0700, Michael Fuhr <mike@fuhr.org> wrote:

> On Sun, Jan 02, 2005 at 01:31:22AM +0000, Oluwatope Akinniyi wrote:
>
>> I tried to create a function with about 60 input parameters and got an
>> error message that a function cannot take more than 32 parameters.
>
> What's the function's purpose?  Why does it need so many arguments?
> You might be able to get around the limitation with a composite
> type, but maybe there's a different way to do what you want.
>
> Another possibility would be to rebuild PostgreSQL and change the
> limit.  I don't know what the implications are other than what the
> comment in the code says: "There is no specific upper limit, although
> large values will waste system-table space and processing time" and
> "Changing these requires an initdb."
>



Re: Function Parameters

From
David Fetter
Date:
On Sun, Jan 02, 2005 at 01:31:22AM +0000, Oluwatope Akinniyi wrote:
> Hi,
>
> Compliments of the season.
>
> I tried to create a function with about 60 input parameters and got
> an error message that a function cannot take more than 32
> parameters.

Generally, a function with that many input parameters is a sign of a
bad function design, rather than of an unreasonable limit in
PostgreSQL.

> Is there a way around this?  Or Am I in error?

Um, how do I put this gently...a function with that many parameters
means it's overwhelmingly likely that you are.

Other people have made suggestions about recompiling PostgreSQL,
hacking the source code, etc., etc.  These are things you should only
attempt when you are absolutely certain that there is no other way to
do what you need to do than with a function of 60 parameters.

Here, "absolutely certain" means "having gone over the design of the
entire application, re-doing all of it if needed," because if you go
down the road of having a hand-hacked PostgreSQL, you severely limit
the community's ability to help you when you encounter a problem.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

Re: Function Parameters

From
Michael Fuhr
Date:
On Sun, Jan 02, 2005 at 12:56:52PM -0800, David Fetter wrote:
>
> Other people have made suggestions about recompiling PostgreSQL,
> hacking the source code, etc., etc.  These are things you should only
> attempt when you are absolutely certain that there is no other way to
> do what you need to do than with a function of 60 parameters.

I mentioned changing the limit in the code and rebuilding but I
hope that wasn't taken as a recommendation to do so.  I'll echo
what David says about rethinking what you're doing (hence my earlier
question about why you need so many parameters).  Hacking the code
should only be a last resort.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/