On Wed, Nov 9, 2016 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah, that's the thread I remembered. I think the basic conclusion was that we needed a Perl script that would suck up a bunch of data from some representation that's more edit-friendly than the DATA lines, expand symbolic representations (regprocedure etc) into numeric OIDs, and write out the .bki script from that. I thought some people had volunteered to work on that, but we've seen no results ...
If there are no barriers to adding it to our toolchain, could that more-edit-friendly representation be a SQLite database?
I'm not suggesting we store a .sqlite file in our repo. I'm suggesting that we store the dump-restore script in our repo, and the program that generates the .bki script would query the generated SQLite db.
From that initial dump, any changes to pg_proc.h would be appended to the dumped script
...
/* add new frombozulation feature */
ALTER TABLE pg_proc_template ADD frombozulator text; /* bubbly frombozulation is the default for volatile functions */
UPDATE pg_proc_template SET frombozulator = 'bubbly' WHERE provolatile = 'v';
/* proposed new function */
INSERT INTO pg_proc_template(proname,proleakproof) VALUES ("new_func",'f');
That'd communicate the meaning of our changes rather nicely. A way to eat our own conceptual dogfood.
Eventually it'd get cluttered and we'd replace the populate script with a fresh ".dump". Maybe we do that as often as we reformat our C code.
I think Stephen Frost suggested something like this a while back, but I couldn't find it after a short search.
