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 print a tree according to some
pretty strict rules. For example, I want a special syntax for function RTEs
and I don't want the v::type notation to be output (the flag to turn it off
doesn't do what I want).

There are lots of uses for 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 work is 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 all of the source-to-source
transformations but before the planning. This was a big help in debugging
the source-to-source transformations I was working on.

As a general rule, you want the list of node types to appear in as few
places as possible in order to increase the maintainability of the code. One
way to do that is with generic walkers like the ones in Postgresql (a nice
solution, by the way). This works well in the case where only a small number
of node types need special consideration. The case of printing different
though. In printing, there is a default thing to do with each node type
--but something different for each type. You want to do the default thing
for most of the nodes, but something special for a few types. The best way I
know to abstract that sort of process is with a table-driven walker.

As for future plans, if you ever get serious about making a big change in
the parsing and tree-manipulating code then you might want to look into some
of the open-source attribute-grammar and tree-transformation software rather
than C++. Those tools are specialized for that kind of work while C++ has
some weaknesses in that area. I think some of these tools have BSD-style
licenses. The downside is that they require the maintainers to know yet
another language. The upside is that they let you work at a higher level of
abstraction. And most of them come with built-in pretty printers :-).

On Thu, Feb 26, 2009 at 11:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Gudeman <dave(dot)gudeman(at)gmail(dot)com> writes:
> > I would replace this with a table-driven deparser:
> > deparse_table[nodeTag(node)](node, context);
>
> I don't actually see what this is going to buy for you. You didn't
> say exactly why ruleutils doesn't work for you, but reading between
> the lines suggests that you want to add new node types. There are
> a *ton* of places that need to change for that, typically, and this
> isn't going to fix it.
>
> I've occasionally speculated about the possible value of switching
> over to method-table-based node types (or maybe just biting the bullet
> and going to C++) but it never really looked like it would be worth
> the trouble.
>
> regards, tom lane
>