There doesn't seem to be any interest in bootstrap data at the moment,
but rather than give up just yet, I've added a couple features to make
a data migration more compelling:
1. Human-readable types, operators, opfamilies, and access methods
2. Column abbreviations
For an example of both practices, an entry from pg_amop changes from
DATA(insert ( 1976 21 21 1 s 95 403 0 ));
to
{ opf => 'btree/integer_ops', lt => 'int2', rt => 'int2', str => '1',
oper => '<(int2,int2)', am => 'btree' },
3. Reduce redundancy in pg_proc data by
-computing pronargs from proargtypes and
-leaving out prosrc if it's just a copy of proname.
This, plus a few column abbreviations drastically shrinks pg_proc.dat
line length, even with human-readable types:
pg_proc.h: avg=175, stdev=25
pg_proc.dat: avg=92, stdev=43
An example before:
DATA(insert OID = 300 ( float48ne PGNSP PGUID 12 1 0 0 0 f f
f t t f i s 2 0 16 "700 701" _null_ _null_ _null_ _null_ _null_
float48ne _null_ _null_ _null_ ));
and after:
{ oid => '300',
n => 'float48ne', lp => 't', p => 's', rt => 'bool', at => 'float4 float8' },
--
I've changed the numbering so that patches with the same number should
be taken as unit, separated only for readability. When referring to
the previous email overview, they map like this:
1-3 : unchanged
4-7 : 4A-4D
8 : N/A - I've left out the SQL generation for now, but I can add it later.
New in this patch set:
Patch 5 rips out the DATA() and DESCR() lines from the headers and
updates the comments to reflect that.
Patches 6A and 6B implement human-readable types etc. as described above.
-John Naylor
