From: "Josh Berkus" <josh@agliodbs.com>
Subject: Re: 16 parameter limit 
To: Tom Lane <tgl@sss.pgh.pa.us>, "Josh Berkus" <josh@agliodbs.com>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
	John Proctor <jproctor@prium.net>, pgsql-sql@postgresql.org
Date: Fri, 05 Apr 2002 14:29:14 -0800
Message-ID: <web-1050830@davinci.ethosmedia.com>
In-Reply-To: <26072.1018030901@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

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.  

As John has discussed, this kind of data structure is relatively common
 in both Oracle and Informix shops.  As such, Postgres emulating this
 ability allows DBAs from those worlds to consider moving to Postgres
 and RHDB.   While the same kind of business logic can be implemented
 through Rules and Triggers, the Postgres structure for these things is
 unique and as a result not very portable.

-Josh Berkus


______AGLIO DATABASE SOLUTIONS___________________________
                                       Josh Berkus
  Complete information technology      josh@agliodbs.com
   and data management solutions       (415) 565-7293
  for law firms, small businesses        fax 621-2533
    and non-profit organizations.      San Francisco