2015-06-28 10:46 GMT+02:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > Hello again Pavel, > > 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. >> > > I'm curious, how many "few" lines? > I am looking to epsql source code http://pgfoundry.org/frs/download.php/2537/psql-enhanced-macros.diff and with more precious estimation less than 200 rows of formatted code (implementation \ifdef) > > 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. Regards Pavel > > -- > Fabien.