[ dept. of second thoughts ] I wrote: > It's easy to make that claim, much less easy to actually do it.
Reflecting on this a bit more ... it seems to me that it's not the right thing to set the goal as "try to get rid of as many DATA statements as possible". The right way to think about this is to classify the stuff we have got in DATA statements, and consider how to reduce the pain associated with the harder-to-maintain categories. In particular, I think Greg correctly identified the main pain point as being the catalog entries associated with operator classes (ie, pg_opclass, pg_opfamily, pg_amop, pg_amproc entries). So what I'm thinking is we should consider how to migrate *all* of those entries into CREATE OPERATOR CLASS/FAMILY commands. And I think that that might be doable. Those entries are not needed by the system until we create catalog indexes. So maybe we could split the current bootstrap phase into three phases: * create core catalogs and load DATA commands, using bki * create operator classes, using sql script * create indexes, using bki * proceed on as before 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers