Jeff,

Disclaimer - this post has *nothing* to do with RAC

It really is quite simple in the arena of application development.

The meaning of a procedure may be applicable to more than a single table. Because of the underlying nature of sql a procedure is usually associated with a particular table. If two tables are candidates for the same outcome (meaning) this usually results in two procedures that do the same thing for 2 different tables. Now you can only pass a table as a parameter to a procedure if the table is a 'variable'. But tables are *not* variables in sql, they are static structures, ie. values/literals/files. So it is necessary to resort to crude workarounds that simulate the idea of a table as a variable, ie. dynamic sql, xml or the Katami idea of a table 'parameter' which is more silliness. The following articles will, I hope, bring the big picture home (assuming they are actually read :

http://beyondsql.blogspot.com/2007/09/dataphor-all-tables-are-typed-variables.html

http://beyondsql.blogspot.com/2007/06/dataphor-13-passing-table-as-parameter.html

http://beyondsql.blogspot.com/2007/08/dataphor-creating-super-function.html

Just because someone is an expert sql programmer does not mean they understand (nor the implications) of the computer science

(types, variables, and values) of that which they are doing. And just

because the 'compute science' of sql is not discussed in Bol certainly

does not mean it doesn't exist. That is the genealogy of sql - a language described as a mile wide and its foundation left an inch deep -

S  - structured

P  - programming

A  - absent

M  - methods