"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
