On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> 2017-01-03 20:54 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>:
>> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule <pavel.steh...@gmail.com>
>> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>:
>> >> *) Would also like to have a FINALLY block
>> > What you can do there?
>> This is syntax sugar so you don't need second begin/end/exception
>> block or duplicated code. It separates error handling from cleanup.
>> PERFORM dblink_connect(...
>> EXCEPTION WHEN OTHERS THEN
>> <log/handle error>
>> PERFORM dblink_disconnect(...
> Does know somebody this pattern from Ada or PL/SQL?
I guess probably not. It's a standard pattern in modern EH languages
(for example, https://msdn.microsoft.com/en-us/library/dszsf989.aspx).
>> >> *) Some user visible mechanic other than forcing SQL through EXECUTE
>> >> to be able to control plan caching would be useful.
>> > fully agree.
>> > Have you some ideas?
>> > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE - any
>> > non
>> > trivial plans will not be cached - and evaluated as parametrized query
>> > only.
>> I have slight preference for syntax marker for each query, similar to
>> INTO. Maybe 'UNCACHED'?
> I am not clean opinion - the statement level is nice, but what readability?
> SELECT UNCACHED t.a, t.b FROM INTO a,b;
Yeah -- this is pretty ugly admittedly. Maybe control directive is
ok, as long as you can set it mid function?
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: