Re: proposal: condition blocks in psql

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: condition blocks in psql
Date: 2015-06-29 12:45:38
Message-ID: CAHyXU0y34SHPRDwxPzB_rTYEH+GBJme6CicjhMkirA_DpiQHDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 28, 2015 at 1:59 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
>>>> \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.

Manual transaction control is the killer feature IMO; not being able
to do it forces code out of sql and into a scripting language.
Transaction management in 'psql scripting' is no more or less fragile
than in most imperative languages.

Personally, I prefer a server side solution to this problem (stored
procedures) so that the application can leverage this functionality
through the protocol. However, psql extensions are probably worth it
in their own right.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-06-29 13:00:46 Re: anole: assorted stability problems
Previous Message Merlin Moncure 2015-06-29 12:23:43 Re: pg_trgm version 1.2