Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan - Mailing list pgsql-hackers

On 19/03/17 12:32, Pavel Stehule wrote:
> 
> 
> 2017-03-18 19:30 GMT+01:00 Petr Jelinek <petr.jelinek@2ndquadrant.com
> <mailto:petr.jelinek@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.stehule@gmail.com <mailto:pavel.stehule@gmail.com>
>     >> <mailto: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()
> 

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