Re: Do we need use more meaningful variables to replace 0 in catalog head files?

<div dir="ltr"><div class="gmail_extra"><br /></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 9,
2016at 10:47 AM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us"
target="_blank">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1pxsolid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-998365091969121879a3s
gmail-m_-998365091969121879aXjCHgmail-m_-998365091969121879m15849c69118e7648"
id="gmail-m_-998365091969121879:1lo">Yeah,that's the thread I remembered.  I think the basic conclusion was<br /> that
weneeded a Perl script that would suck up a bunch of data from some<br /> representation that's more edit-friendly than
theDATA lines, expand<br /> symbolic representations (regprocedure etc) into numeric OIDs, and write<br /> out the .bki
scriptfrom that.  I thought some people had volunteered to<br /> work on that, but we've seen no results
...</div></blockquote></div><br/>If there are no barriers to adding it to our toolchain, could that more-edit-friendly
representationbe a SQLite database?<br /> </div><div class="gmail_extra">I'm not suggesting we store a .sqlite file in
ourrepo. I'm suggesting that we store the dump-restore script in our repo, and the program that generates the .bki
scriptwould query the generated SQLite db.<br /><br />From that initial dump, any changes to pg_proc.h would be
appendedto the dumped script<br /><br /></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div
class="gmail_extra"><fontface="monospace, monospace">...</font></div></blockquote><blockquote style="margin:0 0 0
40px;border:none;padding:0px"><divclass="gmail_extra"><font face="monospace, monospace">/* add new frombozulation
feature*/</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div
class="gmail_extra"><fontface="monospace, monospace">ALTER TABLE pg_proc_template ADD frombozulator text;<br />/*
bubblyfrombozulation is the default for volatile functions */</font></div><div class="gmail_extra"><font
face="monospace,monospace">UPDATE pg_proc_template SET frombozulator = 'bubbly' WHERE provolatile =
'v';</font></div></blockquote><blockquotestyle="margin:0 0 0 40px;border:none;padding:0px"><div
class="gmail_extra"><fontface="monospace, monospace">/* proposed new function */</font></div></blockquote><blockquote
style="margin:00 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace">INSERT INTO
pg_proc_template(proname,proleakproof)VALUES ("new_func",'f');</font></div></blockquote><blockquote style="margin:0 0 0
40px;border:none;padding:0px"><divclass="gmail_extra"><font face="monospace, monospace"><br
/></font></div></blockquote><divclass="gmail_extra"><br />That'd communicate the meaning of our changes rather nicely.
Away to eat our own conceptual dogfood.<br /><br /></div><div class="gmail_extra">Eventually it'd get cluttered and
we'dreplace the populate script with a fresh ".dump". Maybe we do that as often as we reformat our C code.<br /><br />I
thinkStephen Frost suggested something like this a while back, but I couldn't find it after a short search.<br
/></div></div>