Re: Missing dependency tracking for TableFunc nodes

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> I played with this a bit, making the change I proposed, and got lots of
> warnings from the compiler. I don't know how many of these would need
> to be suppressed by adding a no-op for them at the end of the switch vs.
> how many need to be handled, but the attached patch implements the idea.
> I admit adding all these extra cases to the end is verbose....

Yeah, that's why it's not done that way ...

> The change as written is much too verbose to be acceptable, but given
> how many places in the code could really use this sort of treatment, I
> wonder if there is a way to reorganize the NodeTag enum into multiple
> enums, one for each logical subtype (such as executor nodes, plan nodes,
> etc) and then have switches over enums of the given subtype, with the
> compiler helping detect tags of same subtype that are unhandled in the
> switch.

The problem here is that the set of nodes of interest can vary depending
on what you're doing. As a case in point, find_expr_references has to
cover both expression nodes and some things that aren't expression nodes
but can represent dependencies of a plan tree.

I think that the long-term answer, if Andres gets somewhere with his
project to autogenerate code like this, is that we'd rely on annotating
the struct declarations to tell us what to do. In the case at hand,
I could imagine annotations that say "this field contains a function OID"
or "this list contains collation OIDs" and then the find_expr_references
logic could be derived from that. Now, that's not perfect either, because
it's always possible to forget to annotate something. But it'd be a lot
easier, because there'd be tons of nearby examples of doing it right.

regards, tom lane