Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan |
Дата | |
Msg-id | 1272e4cf-c0bd-8ecd-029a-8974904b95ca@BlueTreble.com обсуждение исходный текст |
Ответ на | [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
Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan |
Список | 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 по дате отправления: