Re: a proposal for an extendable deparser

I don't need to add new node types or add any syntax; it is the output that I'm concerned with. What I want is a way to
printa tree according to some pretty strict rules. For example, I want a special syntax for function RTEs and I don't
wantthe v::type notation to be output (the flag to turn it off doesn't do what I want).<br /><br />There are lots of
usesfor specialized pretty-printing. Sometimes you have a simplified syntax reader that can't handle the fully general
syntax.For example, you might write an extension in Perl that needs to understand the parse trees. One way to make this
workis to print out a simplified syntax from the parse tree and then reparse in Perl. Another use is for general
pretty-printing.For example, I modified ruleutils.c to let me print a nice representation of the SQL statement after
allof the source-to-source transformations but before the planning. This was a big help in debugging the
source-to-sourcetransformations I was working on.<br /><br />As a general rule, you want the list of node types to
appearin as few places as possible in order to increase the maintainability of the code. One way to do that is with
genericwalkers like the ones in Postgresql (a nice solution, by the way). This works well in the case where only a
smallnumber of node types need special consideration. The case of printing different though. In printing, there is a
defaultthing to do with each node type --but something different for each type. You want to do the default thing for
mostof the nodes, but something special for a few types. The best way I know to abstract that sort of process is with a
table-drivenwalker.<br /><br />As for future plans, if you ever get serious about making a big change in the parsing
andtree-manipulating code then you might want to look into some of the open-source attribute-grammar and
tree-transformationsoftware rather than C++. Those tools are specialized for that kind of work while C++ has some
weaknessesin that area. I think some of these tools have BSD-style licenses. The downside is that they require the
maintainersto know yet another language. The upside is that they let you work at a higher level of abstraction. And
mostof them come with built-in pretty printers :-).<br /><br /><br /><div class="gmail_quote">On Thu, Feb 26, 2009 at
11:54AM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left:1ex;"><div class="Ih2E3d">Dave Gudeman <<a
href="mailto:dave.gudeman@gmail.com">dave.gudeman@gmail.com</a>>writes:<br /> > I would replace this with a
table-drivendeparser:<br /> >         deparse_table[nodeTag(node)](node, context);<br /><br /></div>I don't actually
seewhat this is going to buy for you.  You didn't<br /> say exactly why ruleutils doesn't work for you, but reading
between<br/> the lines suggests that you want to add new node types.  There are<br /> a *ton* of places that need to
changefor that, typically, and this<br /> isn't going to fix it.<br /><br /> I've occasionally speculated about the
possiblevalue of switching<br /> over to method-table-based node types (or maybe just biting the bullet<br /> and going
toC++) but it never really looked like it would be worth<br /> the trouble.<br /><br />                        regards,
tomlane<br /></blockquote></div><br />