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 for doing 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.c file and making a
few minor changes deep in the file. Of course, copy-and-paste is not a very
maintainable form of code reuse so I'm not too happy with this solution.
What I would like is a generic pretty-printing mechanism that can be
tailored for specific needs. I'm willing to do this work if I think it's
likely to be accepted into the main code line.

Here is the proposal: get_rule_expr() consists of a switch statement that
looks like this:

switch (nodeTag(node))
{
case T_Var:
(void) get_variable((Var *) node, 0, true, context);
break;

case T_Const:
get_const_expr((Const *) node, context, 0);
break;

case T_Param:
appendStringInfo(buf, "$%d", ((Param *) node)->paramid);
break;

case ...

I would replace this with a table-driven deparser:

deparse_table[nodeTag(node)](node, context);

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 generic context object.
To create a modified deparser, you just copy deparse_table[] and replace
some of its members with your own specialized replacements.

The above description is a bit over-simplified. I would probably end up
making 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, for example, and maybe a table of operators. It would support pretty
printing entire queries, not just rules, constraints, and fragments.

I'd lke to get some feedback on this from the Postgres developers. Is there
any interest in this kind of facility? Would it be likely to be accepted?