Re: 16 parameter limit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, John Proctor <jproctor(at)prium(dot)net>, pgsql-sql(at)postgresql(dot)org
Subject: Re: 16 parameter limit
Date: 2002-04-05 23:18:19
Message-ID: 10867.1018048699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches pgsql-sql

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2002-04-05 23:22:50 Re: Suggestion for optimization
Previous Message Peter Eisentraut 2002-04-05 23:11:18 Re: Debugging symbols by default

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-04-05 23:25:03 Re: PQescapeBytea is not multibyte aware
Previous Message Joe Conway 2002-04-05 22:58:41 Re: PQescapeBytea is not multibyte aware

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2002-04-05 23:26:13 Re: 16 parameter limit
Previous Message d_nardini 2002-04-05 22:39:54 intersect performance (PG 7.1.3 vs 7.2)