[ 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*
createindexes, 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
