On Thu, Sep 16, 2021 at 5:40 AM Andres Freund <and...@anarazel.de> wrote: > > > I don't have any better ideas to offer :-( ... but I very much fear > > that the approach proposed here is a dead end. > > I unfortunately don't see a good way forward without changing the way we do > parsing on a more fundamental level :(.
Using the ExtensibleNode infrastructure, I can see two ways to try to leverage that. First one would be to require modules to wrap their RawStmt->stmt in an ExtensibleNode if they want to do anything that requires semantic analysis, and handle such node in transformStmt() with another hook. I think it would allow modules to do pretty much anything, at the cost of walking the stmt twice and duplicating possibly huge amount of analyze.c and friends. The other one would be to allow the parser to leak ExtensibleNode in the middle of the RawStmt and catch them in the transform* functions, with e.g. some generic transformExtensibleNode(pstate, node, some_identifier...) (the identifier giving both the general transform action and some secondary info, like ParseExprKind for expressions). This would avoid the downsides of the first approach, but would require to call this new hook in a bunch of places. Or we could combine both approaches so that the most common use cases, like transformExprRecurse(), would be easily handled while more exotic cases will have to go the hard way. Parser authors could still ask for adding a new call to this new hook to ease their work in the next major version. Would any of that be a reasonable approach?
