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> >> wrote: >> > 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. >> >> BEGIN >> PERFORM dblink_connect(... >> <risky_stuff> >> EXCEPTION WHEN OTHERS THEN >> <log/handle error> >> FINALLY >> PERFORM dblink_disconnect(... >> END; > > > 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? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
