Обсуждение: Function Parameters

Поиск
Список
Период
Сортировка

Function Parameters

От
"Oluwatope Akinniyi"
Дата:
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

От
Michael Fuhr
Дата:
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

От
Pierre-Frédéric Caillaud
Дата:
    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

От
David Fetter
Дата:
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

От
Michael Fuhr
Дата:
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/