To: "Josh Berkus" <josh@agliodbs.com>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
	John Proctor <jproctor@prium.net>, pgsql-sql@postgresql.org
Subject: Re: 16 parameter limit 
In-reply-to: <web-1050830@davinci.ethosmedia.com> 
References: <web-1050830@davinci.ethosmedia.com>
Comments: In-reply-to "Josh Berkus" <josh@agliodbs.com>
	message dated "Fri, 05 Apr 2002 14:29:14 -0800"
Date: Fri, 05 Apr 2002 18:18:19 -0500
Message-ID: <10867.1018048699@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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.  

Yeah, but if we had slightly better support for rowtype parameters in
plpgsql, you could do it with *three* parameters: session, user, and
contents of record as a clients%rowtype structure.  And it'd probably
be a lot easier to read, and more maintainable in the face of changes
to the clients table structure.  This is why I say that needing lots
of parameters may be a symptom of missing features rather than an
indication that we ought to push up FUNC_MAX_ARGS.

			regards, tom lane