Before I start hacking on this, I'd like to share my thoughts.
Looking at the code, I think that a validator could be added quite soon. The PLpgSQL_execstate struct could be extended by a validation_active bool flag, which changes the behaviour of all exec_stmt_XXX routines. The validator primarily executes the function, with that flag to TRUE, forcing all conditional statements to execute all execution paths exactly once, and sql statements being parsed.
Debugging is much harder.
There are two levels of debugging thinkable: full-blown stepping with breakpoints etc while running in the backend, and the small version having an intelligent console which simulates a backend understanding plpgsql language natively, so you can test the code by executing single blocks of code one after another (i.e not storing the function, but selectively executing parts of the function definition).
Backend debugging seems not possible the way the code is structured now. The execution path is stored on the backend program stack, so it's virtually impossible to interrupt the execution at a point for later continuation. The backend's flow of execution is identical with plpgsql's, interrupting plpgsql means stopping the backend.
Frontend debugging seems more feasible, by offering some functions, that enables a caller to initialize variables, call a statement block (that's compiled immediately, executed and discarded), and retrieve all vars.
Any thoughts about this? More caveats I haven't seen?
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
