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.

Reply via email to