+1 on the idea. It'd also be nice if we could expose control of plans for dynamic SQL, though I suspect that's not terribly useful without some kind of global session storage.
A couple notes on a quick read-through:
Instead of paralleling all the existing namespace stuff, I wonder if it'd be better to create explicit block infrastructure. AFAIK PRAGMAs are going to have a lot of the same requirements (certainly the nesting is the same), and we might want more of this king of stuff in the future. (I've certainly wished I could set a GUC in a plpgsql block and have it's settings revert when exiting the block...)
I am not sure if I understand. ?? Setting GUC by PRAGMA can work - the syntax supports it and GUC API supports nesting. Not sure about exception handling - but it should not be problem probably.
Please, can you show some examples.
Perhaps that's as simple as renaming all the existing _ns_* functions to _block_ and then adding support for pragmas...
Since you're adding cursor_options to PLpgSQL_expr it should probably be removed as an option to exec_*.
I have to recheck it. Some cursor options going from dynamic cursor variables and are related to dynamic query - not query that creates query string.
hmm .. so current state is better due using options like CURSOR_OPT_PARALLEL_OK
This options is not permanent feature of expression - and then I cannot to remove cursor_option argument from exec_*
I did minor cleaning - remove cursor_options from plpgsql_var
Regards
Pavel
finit_ would be better named free_.
good idea
Regards
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)