Michael Meskes <meskes@postgresql.org> forwards:
> Currently, only a very limited range of information about arguments
> and return values of PostgreSQL database functions are available
> from pg_proc: the basic type and the order of the arguments.
> Other important properties like precision, length, default values or
> even descriptive names for the arguments are missing.
This seems to be predicated on the assumption that these properties
would exist if only there were table columns to store them.
In point of fact, function arguments and results do not have precision
or length, as a rule.
Addition of default values sounds like a nice idea in principle but in
practice it plays hob with the system's ability to choose a matching
function --- if I write foo(1,2), that could match not only foo(int,int)
but foo(int,int,almost-anything) if there are defaults available for
arguments of the second version of foo. That needs very careful thought
before we buy into it.
Names for arguments would be nice, but they are not really worth a
wholesale restructuring of pg_proc; a per-argument comment facility
would serve the need as well or better.
Finally, the reason pg_proc is not normalized is that it's necessary to
allow reasonable lookup of functions by signature. How would you
enforce "only one function named foo of arguments x,y,z" in the proposed
restructured catalog? It's certainly not as easy as making a unique index.
> Adding a column for descriptive remarks for
> each column would not be too bad for ordinary table columns anyway...
See pg_description.
regards, tom lane
