On 16/03/17 17:15, David Steele wrote: > On 2/1/17 3:59 PM, Pavel Stehule wrote: >> Hi >> >> 2017-01-24 21:33 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com >> <mailto:pavel.stehule@gmail.com>>: >> >> 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 >> >> if (expr->plan == NULL) >> exec_prepare_plan(estate, expr, (parallelOK ? >> CURSOR_OPT_PARALLEL_OK : 0) | >> expr->cursor_options); >> >> 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 >> >> + basic doc > > This patch still applies cleanly and compiles at cccbdde. > > Any reviewers want to have a look? >
I'll bite.
I agree with Jim that it's not very nice to add yet another block/ns-like layer. I don't see why pragma could not be added to either PLpgSQL_stmt_block (yes pragma can be for whole function but function body is represented by PLpgSQL_stmt_block as well so no issue there), or to namespace code. In namespace since they are used for other thing there would be bit of unnecessary propagation but it's 8bytes per namespace, does not seem all that much.
My preference would be to add it to PLpgSQL_stmt_block (unless we plan to add posibility to add pragmas for other loops and other things) but I am not sure if current block is easily (and in a fast way) accessible from all places where it's needed. Maybe the needed info could be pushed to estate from PLpgSQL_stmt_block during the execution.
There is maybe partial misunderstand of pragma - it is set of nested configurations used in compile time only. It can be used in execution time too - it change nothing.
The pragma doesn't build a persistent tree. It is stack of configurations that allows fast access to current configuration, and fast leaving of configuration when the change is out of scope.
I don't see any any advantage to integrate pragma to ns or to stmt_block. But maybe I don't understand to your idea.
I see a another possibility in code - nesting init_block_directives() to plpgsql_ns_push and free_block_directives() to plpgsql_ns_pop()
