Re: Functions have 32 args limt ???

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:24253(dot)1062087102(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> "Ivar" <ivar(at)lumisoft(dot)ee> writes:
> > Are there any real pefrormance difference, what are actual
difference(%),
> > have somebody measured even it ?
>
> You still haven't looked at the thread you were pointed to, have you?
>
> There is another issue besides disk space and performance, which is that
> functions with large numbers of positional parameters are just plain bad
> style --- it's way too easy to introduce bugs by passing the parameters
> in the wrong order. It's usually better to coalesce some of the
> parameters into arrays or records. Our awareness of this fact keeps us
> from wanting to expend lots of work or resources on making the standard
> function argument limit larger.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

I found some threads now:

Seems there is big fuss around this.
Table sizes are increasing ok, complaining IO penaly, but no reallife speed
panalty size (%)

http://groups.google.com/groups?q=FUNC_MAX_ARGS&start=20&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=10867.1018048699%40sss.pgh.pa.us&rnum=28
{
"Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> Tom,
>> 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.
> No, not really. It's just people wanting to use PL/pgSQL procedures as
> data filters. For example, I have a database with complex
> dependancies and validation rules that I started under 7.0.3, when
> RULES were not an option for such things and triggers were harder to
> write. As a result, I have the interface push new records for, say,
> the CLIENTS table through a PL/pgSQL procedure rather than writing to
> the table directly. Since the table has 18 columns, I need (18 + 2
> for session & user) 20 parameters for this procedure.

There is another reallife situation where is needed more args.
(Basically functions can't be used for INSERT)
}

> in the wrong order. It's usually better to coalesce some of the
> parameters into arrays or records.
How you pass array from c# though odbc to sql server ???

Seems I must wait some time, I'm sure that this limit is removed future
releases.

Just curious how other servers handle this ?
MS SQL defenitely works
Orcale ??
Db2 ??
SAP DB, works
Firebird ??

"Ivar" <ivar(at)lumisoft(dot)ee> wrote in message news:bil8fc$t0$1(at)sea(dot)gmane(dot)org(dot)(dot)(dot)
>
> > Did you even bother to look at the thread I referred to?
> What thread ?
> You just gave some notes how to come over this, but I think I'll never use
> modified source
> and not standard release server.
>
> If you see my example of my functions (trying to move ms sql to postgre,
all
> goes well except it),
> is them really so dummy or bad design.
>
> > greater than 32 arguments why they should suffer a performance hit just
> > because you do.
> Are there any real pefrormance difference, what are actual difference(%),
> have somebody measured even it ?
>
> "Joe Conway" <mail(at)joeconway(dot)com> wrote in message
> news:3F4E2126(dot)6010902(at)joeconway(dot)com(dot)(dot)(dot)
> > Ivar wrote:
> > > I don't see why default is so small.
> > >
> >
> > Did you even bother to look at the thread I referred to?
> >
> > There was a lengthy discussion on the pros and cons of various default
> > settings, and the consensus of the community was 32. If you'd like to
> > make a cogent argument for why it ought to be higher, by all means do
> > so. But you'll have to convince quite a few people who have no need for
> > greater than 32 arguments why they should suffer a performance hit just
> > because you do.
> >
> > Joe
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>