Re: Do we need use more meaningful variables to replace 0 in catalog head files? - Mailing list pgsql-hackers
From | Corey Huinker |
---|---|
Subject | Re: Do we need use more meaningful variables to replace 0 in catalog head files? |
Date | |
Msg-id | CADkLM=ffcQMCeWx+fUmO7HiZoHXa-P0y7F9gBKzxCDkSma=GKQ@mail.gmail.com Whole thread Raw |
In response to | Re: Do we need use more meaningful variables to replace 0 in catalog head files? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Do we need use more meaningful variables to replace 0 in catalog head files?
|
List | pgsql-hackers |
<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>
pgsql-hackers by date: