Re: proposal: condition blocks in psql - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: proposal: condition blocks in psql
Date
Msg-id CAHyXU0y34SHPRDwxPzB_rTYEH+GBJme6CicjhMkirA_DpiQHDQ@mail.gmail.com
Whole thread Raw
In response to Re: proposal: condition blocks in psql  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Sun, Jun 28, 2015 at 1:59 AM, Fabien COELHO <coelho@cri.ensmp.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



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: pg_trgm version 1.2
Next
From: Andres Freund
Date:
Subject: Re: anole: assorted stability problems