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

2017-09-08 21:21 GMT+02:00 Daniel Gustafsson <daniel(at)yesql(dot)se>:

> > On 08 Sep 2017, at 19:14, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > On 6 September 2017 at 07:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> >> LET custom_plan_tries = 0 IN SELECT ...
> >
> > Tom has pointed me at this proposal, since on another thread I asked
> > for something very similar. (No need to reprise that discussion, but I
> > wanted prepared queries to be able to do SET work_mem = X; SELECT).
> > This idea looks a good way forward to me.
> >
> > Since we're all in roughly the same place, I'd like to propose that we
> > proceed with the following syntax... whether or not this precisely
> > solves OP's issue on this thread.
> >
> > 1. Allow SET to set multiple parameters...
> > SET guc1 = x, guc2 = y
> > This looks fairly straightforward
> >
> > 2. Allow a SET to apply only for a single statement
> > SET guc1 = x, guc2 = y FOR stmt
> > e.g. SET max_parallel_workers = 4 FOR SELECT count(*) FROM bigtable
> > Internally a GUC setting already exists for a single use, via
> > GUC_ACTION_SAVE, so we just need to invoke it.
>
> This syntax proposal makes sense, +1. My immediate thought was that the
> per-statement GUCs were sort of like options, and most options in our
> syntax
> are enclosed with (), like: SET (guc1 = x, guc2 = y) FOR SELECT ..;
>

we newer support this syntax in combination with SET keyword

see - CREATE FUNCTION command

personally I prefer syntax without FOR keyword - because following keyword
must be reserved keyword

SET x = .., y = .. SELECT ... ;

Regards

Pavel

> cheers ./daniel
>