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

From Jim Nasby
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan
Date
Msg-id 1272e4cf-c0bd-8ecd-029a-8974904b95ca@BlueTreble.com
Whole thread Raw
In response to [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 generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 1/23/17 2:10 PM, Pavel Stehule wrote:
> Comments, notes?

+1 on the idea. It'd also be nice if we could expose control of plans 
for dynamic SQL, though I suspect that's not terribly useful without 
some kind of global session storage.

A couple notes on a quick read-through:

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

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_*.

finit_ would be better named free_.
-- 
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)



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] Undefined psql variables
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory