On 1/12/18 12:24, Alvaro Herrera wrote:
> 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.
> 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.
I don't think I like this. I know pg_proc.h is a pain to manage, but at
least right now it's approachable programmatically. I recently proposed
to patch to replace the columns proisagg and proiswindow with a combined
column prokind. I could easily write a small Perl script to make that
change in pg_proc.h, because the format is easy to parse and has one
line per entry. With this new format, that approach would no longer
work, and I don't know what would replace it.
> 3. references to objects in other catalogs are by name, such as "int8"
> or "btree/integer_ops" rather than OID.
I think we could already do this by making more use of things like
regtype and regproc. That should be an easy change to make.
> 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'm afraid a key value system would invite writing the attributes in
random order and create a mess over time.
But if we want to do it, I think we could also add it to the current BKI
format. The same goes for defining default values for some columns.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
