Re: a proposal for an extendable deparser - Mailing list pgsql-hackers
From | Dave Gudeman |
---|---|
Subject | Re: a proposal for an extendable deparser |
Date | |
Msg-id | 7b079fba0902262353g300f98edqd61a9eb61f7b12fb@mail.gmail.com Whole thread Raw |
In response to | Re: a proposal for an extendable deparser (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: a proposal for an extendable deparser
|
List | pgsql-hackers |
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 />
pgsql-hackers by date: