Peter Eisentraut wrote:
> 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.
The idea in my mind is that you'd write a Perl program to do such
changes, yeah. If the code we supply contains enough helpers and a few
samples, it should be reasonably simple for people that don't do much
Perl.
The patch series does contain a few helper programs to write the data
files. I haven't looked in detail what can they do and what they cannot.
> > 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.
Well, that assumes we *like* the current format, which I think is not a
given ... more the opposite.
> > 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.
Yeah, I share this concern. But you could fix it if the Perl tooling to
write these files had a hardcoded list to work with. Maybe we could put
it in a declaration of sorts at the start of each data file.
> 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.
As above -- do we really like our current format so much that we're
satisfied with minor tweaks?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
