RFC: Restructuring pg_aggregate

I was originally planning to revise pg_aggregate along the same lines
as pg_proc and so forth: add an aggnamespace column and fix the search
code to be namespace-aware.  But it seemed a tad annoying that standard
function lookups would thereby incur *two* namespace-aware searches:
one in pg_aggregate and one in pg_proc.  Thinking about that, it
occurred to me that there is another way.  Why shouldn't aggregate
functions have entries in pg_proc?  Then one search would cover both
possibilities, and we could eliminate some duplicate code in the parser.

Doing things this way would mean that one could not create an aggregate
function with the same name and input arguments as a regular function
(at least, not in the same namespace).  However, doing so has always
been a bad idea, and it seems like it'd be a step forward not back for
the system to reject it as a naming conflict.

A more serious objection is that this will break client applications
that know about the pg_aggregate table.  However, 7.3 is already going
to force a lot of reprogramming of clients that inspect system tables,
because of the addition of namespaces.  Restructuring pg_aggregate
doesn't seem like it makes life all that much worse.

I would envision this working like so:

In pg_proc: add a boolean column "proisagg" to mark function entries
that are aggregates.  A row for an aggregate function would contain
a pointer to a dummy C function that would just raise an error if
called (which shouldn't ever happen, but just in case some bit of
code doesn't get updated, this would be a good safety check).

In pg_aggregate: remove the columns aggname, aggowner, aggbasetype,
aggfinaltype, and add a column aggfnoid containing the OID of the
aggregate's pg_proc row.  (pg_aggregate itself doesn't need OIDs
anymore, and its only index will be on aggfnoid.)  Essentially this
reduces pg_aggregate to an auxiliary extension of pg_proc, carrying
the fields aggtransfn, aggfinalfn, aggtranstype, agginitval for those
pg_proc rows that need them.

An interesting aspect of this is that the catalog structure would now
be prepared to support aggregate functions with more than one input,
which is a feature we've been asked for occasionally.  I am *not*
volunteering to make that happen right now ... but the catalog
structures would be ready for it.

Comments, objections, better ideas?
        regards, tom lane