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

but keep in mind, if Oracle had a hard limit of 32 args, and you needed
33, you'd be hosed, because it's closed source.

PostgreSQL is available in the same format that the developers are working
on, and you can always compile it to handle more than 32 parameters.

Since you can make the change, there's no reason for me and the thousands
of other users who will NEVER use 32 or more args to pay the price in
performance just so you don't have to recompile and reinitdb.

I.e. the majority of users are quite happy with the trade off of
performance / # of args we currently have, and you have it well within
your power to edit the max number of args and recompile, so we should all
be happy to have such a solid, reliable, HACKABLE database at our
disposal.

:-)

On Thu, 28 Aug 2003, Ivar wrote:

> "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
> >
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>