On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> I'm not nearly as excited about migrating all or even most of, say,
> the pg_proc DATA lines into SQL. That simply isn't going to buy very
> much in maintainability --- a patch that wants to add a new property
> to all the functions is going to conflict just as much with another
> patch doing the same. And it is going to cost us in places like
> how do we generate the fmgr lookup table.
>
> Thoughts?
I think it would actually buy you quite a bit to migrate them to SQL,
because in SQL, default properties can generally be omitted, which
means that a patch which adds a new property to pg_proc that takes the
same value for every row doesn't actually need to touch the SQL at
all. I suspect that's a pretty common case, too: SE-PostgreSQL
modifies a whole bunch of system catalogs to add a security label
attribute, and ALTER TABLE ... ALTER COLUMN ... SET DISTINCT adds a
column to pg_attribute that defaults to 0.
I can hear you objecting that there's no possible way we can use SQL
to construct pg_attribute, and that's certainly true. But I have
another idea. What we could do is generate the BKI but using some
more sophisticated method than just writing it all out longhand in the
header files and copying it over into the bki file. The pg_attribute
entries for the bootstrap tables, for example, are mostly inferrable
from the PG_CATALOG() declarations (I think storage class and maybe
one other property might be problematic). And certainly you could
design a more human readable format for the pg_proc entries, maybe
something like:
DATA_PG_PROC(function-name, function-arg1-type-name
function-arg2-type-name,
function-return-type-name,language,definition)
To convert this into BKI, you make an initial pass through pg_type.h
and collect the OIDs of all the type names. Then you zip through
pg_proc.h and now you have enough information to map all the type
names into OIDs and generate the BKI. I'm waving my hands a little
bit here but I really don't think this is too hard, coding-wise, and
it seems like it would make it a LOT easier to edit this file...
...Robert
