RFC: Restructuring pg_aggregate - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | RFC: Restructuring pg_aggregate |
Date | |
Msg-id | 23941.1018078038@sss.pgh.pa.us Whole thread Raw |
Responses |
Re: RFC: Restructuring pg_aggregate
(Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: RFC: Restructuring pg_aggregate (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-hackers |
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
pgsql-hackers by date: