Note that I'm not against cpp-like features on principle, I did macros for apache configurations a very long time ago, and that I only give my 0.02€ on this, for what's the € is worth these days:-)
you can use parameters for functions, but you cannot it for DO statement (simply).
Indeed. Maybe this is worth improving independently of adding conditionals. Not sure about a (clean) syntax, though... Maybe psql could export its variables somehow to PL/pgSQL. Hmmm.
I proposed it some time - but it was rejected - and in this case, I am thinking, so conditional block can be cleaner in psql side. I am playing with psql long time - and I changed my opinion about full scripting support in psql - http://okbob.blogspot.cz/2009/12/enhanced-psql-console-second-version.html (the more complex scripts are unreadable in psql). Instead this I would to support integration psql with some other languages - in this moment I like lua language. But conditional blocks in psql is little bit different topic. I really don't want to open Pandora's box :).
the implementation of \if_version_gt is pretty simple - needs few lines of new code.
You would need a stack to manage nesting, you need some kind of more or less condition evaluation which is open-ended in itself, you need reading up to the end token (possibly this is more or less already available), you need adapting the prompt to reflect the nesting, you need to deal with badly nested scripts (say can an included file be "badly nested" on \i?), you need to decide what to put in the input line history, depending on the available infrastructure within psql...
you don't need it for \if \else \endif. In this case you can ignore some lines from input. You have to check unexpected end and unexpected begin.
I would say 100-300 few lines (but I may be proven wrong both ways), all that for something which is already more or less doable with PL/pgSQL. I would rather try to upgrade the PL/pgSQL experience.
What do you think? I afraid, so there is not too space for experiments there.
