Hi 2017-01-23 21:59 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>:
> On 1/23/17 2:10 PM, Pavel Stehule wrote: > >> Comments, notes? >> > > +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. > > 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) >
