The current implementation of plpgsql lacks some details that makes
programming really hard: there's no language validator to check the code
when creating the function, and there's support to debug the code.
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
