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

From David Steele
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Date
Msg-id e3731aa0-678c-79e9-430f-0d68c90fb077@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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?

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: [HACKERS] Re: Floating point comparison inconsistencies of the geometrictypes
Next
From: David Steele
Date:
Subject: Re: [HACKERS] pgbench more operators & functions