On 19/03/17 12:32, Pavel Stehule wrote: > > > 2017-03-18 19:30 GMT+01:00 Petr Jelinek <petr.jeli...@2ndquadrant.com > <mailto:petr.jeli...@2ndquadrant.com>>: > > 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.steh...@gmail.com > <mailto:pavel.steh...@gmail.com> > >> <mailto:pavel.steh...@gmail.com <mailto:pavel.steh...@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() >
That's more or less what I mean by "integrating" to ns :) The main idea is to not add 3rd layer of block push/pop that's sprinkled in "random" places. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
