Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Jim Nasby <Jim.Nasby@bluetreble.com>
Date: 2017-09-08T21:14:15Z
Lists: pgsql-hackers 
Merlin Moncure <mmoncure@gmail.com> writes:
> We already have 'SET LOCAL', which manages scope to the current
> transaction.  How about SET BLOCK which would set until you've left
> the current statement block?

(1) I do not think this approach will play terribly well in any of the
PLs; their notions of statement blocks all differ from whatever we might
think that is at the interactive-SQL-command level.

(2) AIUI the feature request is specifically for a single-statement
variable change, not any larger scope than that.

			regards, tom lane

Commits

  1. Add plan_cache_mode setting

  2. Add some noreturn attributes to help static analyzers

  3. document when PREPARE uses generic plans

  4. Redesign the plancache mechanism for more flexibility and efficiency.