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
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 |