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

From Petr Jelinek
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan
Date
Msg-id 72a70e17-84eb-8939-7b2f-ec088f549e2f@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] New CORRESPONDING clause design
Next
From: Elvis Pranskevichus
Date:
Subject: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.