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 07:42:42
Message-ID: CAFj8pRDib_VHf40VFKAZ+nA=f7aPVA4pEhP13QO_TGRFtTA0mg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-06-28 8:59 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> \if_ver_eq 9.2
>>>>
>>>
>>> What do you thinking about it?
>>>
>>> Couldn't this kind of thing be done directly with PL/pgSQL?
>>>
>>
>> you can use PL/pgSQL - but there are some limits
>>
>> * maintenance large plpgsql functions
>>
>
> I agree with large but that would not necessarily mean complex. Also, some
> functions could be in SQL, and just the logic with PL/pgSQL.
>
> * the plpgsql functions or anonymous functions create a transaction
>> borders
>> - what should not be wanted
>>
>
> Hmmm... If something fails when installing an extension, a transaction
> border is probably a good thing? Also, the interaction of \if with possible
> BEGIN/COMMIT can lead to strange states.
>
> * I cannot to use psql variables simply in plpgsql code (plpgsql has not
>> any macro language)
>>
>
> You can call a function with a variable as an argument:
>
> \set foo 1234
> SELECT some_function(:foo);
>
> - so some patterns are implemented in plpgsql less readable
>>
>
> Which pattern?
>

you can use parameters for functions, but you cannot it for DO statement
(simply).

>
> for example, if you can create a script that create some plpgsql function
>> for specified PostgreSQL version, then using PLpgSQL for this purpose is
>> suboptimal due less readability and maintainability
>>
>
> I'm not that sure about the qualitative assessment, "DO" looks pretty neat
> to me.
>

I can do with DO almost all work, but the result is not readable - I have
to play with session variables, I have to play with more levels of custom
string separator than is necessary

Moreover this is to be balanced with creating a scope/block/nesting system
> in psql which is currently alien to it and would bring its own pitfalls:
> psql is really intrinsically line/statement oriented, that would not be the
> case with what you're proposing as this logic would be deeply changed, and
> people would get stuck within a non-closed \if, this would interact with \i
> in possibly strange ways, and so on (say you include a file with a non
> closed \if, and then everything you type seems to be ignored, or a BEGIN is
> done in an if but the COMMIT was in another which was not activated because
> the conditions where not consistent...).
>
> Basically, it looks like a potential Pandora box which is best left with
> its lid on.
>

I don't propose full psql scripting - my proposal is much more enhancing
the current psql macro possibilities.

the implementation of \if_version_gt is pretty simple - needs few lines of
new code

>
> --
> Fabien.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-06-28 07:50:44 Re: proposal: condition blocks in psql
Previous Message Fabien COELHO 2015-06-28 07:04:49 Re: proposal: condition blocks in psql