Horton

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

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:16:05Z
Lists: pgsql-hackers 
On Fri, Sep 8, 2017 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > personally I prefer syntax without FOR keyword - because following
> keyword
> > must be reserved keyword
>
> > SET x = .., y = .. SELECT ... ;
>
> Nope.  Most of the statement-starting keywords are *not* fully reserved;
> they don't need to be as long as they lead off the statement.  But this
> proposal would break that.  We need to put FOR or IN or another
> already-fully-reserved keyword after the SET list, or something's going
> to bite us.
>

Just throwing it ​out there but can we making putting SET inside a CTE work?

David J.

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.