Re: PoC plpgsql - possibility to force custom or generic plan

On 1/23/17 11:38 PM, Pavel Stehule wrote:
>
>     Instead of paralleling all the existing namespace stuff, I wonder if
>     it'd be better to create explicit block infrastructure. AFAIK
>     PRAGMAs are going to have a lot of the same requirements (certainly
>     the nesting is the same), and we might want more of this king of
>     stuff in the future. (I've certainly wished I could set a GUC in a
>     plpgsql block and have it's settings revert when exiting the block...)
>
>
> I am not sure if I understand. ?? Setting GUC by PRAGMA can work - the
> syntax supports it and GUC API supports nesting. Not sure about
> exception handling - but it should not be problem probably.
>
> Please, can you show some examples.

 From a code standpoint, there's already some ugliness around blocks: 
there's the code that handles blocks themselves (which IIRC is 
responsible for subtransactions), then there's the namespace code, which 
is very separate even though namespaces are very much tied to blocks. 
Your patch is adding another layer into the mix, separate from both 
blocks and namespaces. I think it would be better to combine all 3 
together, or at least not make matters worse. So IMHO the pragma stuff 
should be part of handling blocks, and not something that's stand alone. 
IE: make the pragma info live in PLpgSQL_stmt_block.

GUCs support SET LOCAL, but that's not the same as local scoping because 
the setting stays in effect unless the substrans aborts. What I'd like 
is the ability to set a GUC in a plpgsql block *and have the setting 
revert on block exit*.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)