Alvaro Herrera <alvherre@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
