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>>: >> >> 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. -- 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
