a proposal for an extendable deparser

While writing a shared-library extension for Postgres, I needed to output SQL expressions from trees. The only facility
fordoing that seems to be the deparse code in ruleutils.c, which is really intended for outputing rules and
constraints,not for producing general SQL, so it didn't do quite what I wanted. I ended up having to copy the entire
ruleutils.cfile and making a few minor changes deep in the file. Of course, copy-and-paste is not a very maintainable
formof code reuse so I'm not too happy with this solution. What I would like is a generic pretty-printing mechanism
thatcan be tailored for specific needs. I'm willing to do this work if I think it's likely to be accepted into the main
codeline.<br /><br />Here is the proposal: get_rule_expr() consists of a switch statement that looks like this:<br
/><br/>    switch (nodeTag(node))<br />    {<br />        case T_Var:<br />            (void) get_variable((Var *)
node,0, true, context);<br />             break;<br /><br />        case T_Const:<br />           
get_const_expr((Const*) node, context, 0);<br />            break;<br /><br />        case T_Param:<br />           
appendStringInfo(buf,"$%d", ((Param *) node)->paramid);<br />             break;<br /><br />        case ...<br
/><br/>I would replace this with a table-driven deparser:<br /><br />        deparse_table[nodeTag(node)](node,
context);<br/><br />where deparse_table[] is an array of function pointers containing functions similar to
get_variable(),get_const_expr(), etc. The functions would have to be adapted to a consistent signature using a more
genericcontext object. To create a modified deparser, you just copy deparse_table[] and replace some of its members
withyour own specialized replacements.<br /><br />The above description is a bit over-simplified. I would probably end
upmaking deparse_table[] into a struct with various flags and user-defined data in addition to the table of function
pointers.Also, it might have more than one table of function pointers. I think a table of RTE types would be useful,
forexample, and maybe a table of operators. It would support pretty printing entire queries, not just rules,
constraints,and fragments.<br /><br />I'd lke to get some feedback on this from the Postgres developers. Is there any
interestin this kind of facility? Would it be likely to be accepted?<br /><br />