On Fri, Jan 12, 2018 at 04:22:26PM -0500, 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.
How about ingesting with Perl, manipulating there, and spitting back
out as Perl data structures?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
