Re: proposal: condition blocks in psql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: condition blocks in psql
Date: 2015-06-28 09:43:06
Message-ID: CAFj8pRBM4X-n1Au-MROjSh+393PAjt31qt4=_w035mDe7Ch81A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-06-28 10:46 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-06-28 10:30:48 Re: Support for N synchronous standby servers - take 2
Previous Message Sawada Masahiko 2015-06-28 08:52:36 Re: Support for N synchronous standby servers - take 2