Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> So could we have an explanation of what it is we're agreeing to?
> Here's a small sample pg_proc entry: > { oid => '2147', descr => 'number of input rows for which the input > expression is not null', > n => 'count', proisagg => 't', v => 'i', p => 's', rt => 'int8', at => > 'any', s => 'aggregate_dummy' }, > An pg_amop entry: > { opf => 'btree/integer_ops', lt => 'int2', rt => 'int2', str => '1', oper => > '<(int2,int2)', am => 'btree' }, > Notes: > 1. this is Perl data; it is read with 'eval' without any external modules. Check. Where is it coming from --- I suppose we aren't going to try to store this in the existing .h files? What provisions will there be for comments? > 2. the pg_proc entry has been compressed to two lines, to avoid > content-free lines that would easily confuse git merge, but keep line > length reasonable. Seems like we would almost need a per-catalog convention on how to lay out the entries, or else we're going to end up (over time) with lots of cowboy coding leading to entries that look randomly different from the ones around them. > 3. references to objects in other catalogs are by name, such as "int8" > or "btree/integer_ops" rather than OID. +1 > 4. for each attribute, an abbreviation can be declared. In the > pg_proc sample we have "n" which stands for proname, because we have > this line: > + NameData proname BKI_ABBREV(n); I think single-letter abbreviations here are a pretty bad space vs readability tradeoff, particularly for wider catalogs where it risks ambiguity. The pg_amop sample you show looks noticeably more legible than the other one. Still, this is something we can debate on a case-by-case basis, it's not a defect in the mechanism. One other question is how we'll verify the conversion. Is there an expectation that the .bki file immediately after the conversion will be identical to immediately before? regards, tom lane