Re: Functions have 32 args limt ??? - Mailing list pgsql-general

"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:24253.1062087102@sss.pgh.pa.us...
> "Ivar" <ivar@lumisoft.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@postgresql.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@agliodbs.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@lumisoft.ee> wrote in message news:bil8fc$t0$1@sea.gmane.org...
>
> > 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@joeconway.com> wrote in message
> news:3F4E2126.6010902@joeconway.com...
> > 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
>