Helo Craig,
I'm a smidge worried about this. It seems like psql is growing a scripting language.
The patch is about aligning pgbench with psql, which already has \if.
Do we want to go our own way with a kind of organically grown scripting system? Or should we be looking at embedding client-side scripting in a more structured, formal way instead? Embed a lua interpreter or something?
My 0.02€ is that the point is to deal with useful/needed simple client capabilities while integrating gracefully with bare server-side executed SQL.
As for useful client-side capabilities, for both psql & pgbench ISTM that it is more in line with a limited cpp-like thing: include, expressions, variables, conditions... maybe minimal error handling. No loop.
As for a language interpreter, it would raise the question of which language (lua, tcl, python, perl, VB, sh, R, ...) and the graceful (upward compatible) integration of any such language: eg how do have pieces of bare SQL and any other existing language would require some scanning conventions that do not exist.
psql & pgbench already have ":x" variables. psql has the ability to set variable from SQL (\gset), and pgbench could do limited expressions to set these variables with (\set), which have been extended to be more complete , and there was use cases which motivate an (\if).
ISTM enough to align both tools for reasonnably simple use cases that could arise when running a basic SQL script of bench. If you have something really complicated, then full fledge programming is the answer, which cannot be bare-SQL compatible.
So the answer is that it is okay to aim at "limited" scripting because it covers useful use cases.
-- Fabien.
