On Fri, Sep 8, 2017 at 2:48 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2017-09-08 21:21 GMT+02:00 Daniel Gustafsson <dan...@yesql.se>: >> >> > On 08 Sep 2017, at 19:14, Simon Riggs <si...@2ndquadrant.com> wrote: >> > >> > On 6 September 2017 at 07:43, Robert Haas <robertmh...@gmail.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 ... ;
This seems pretty ugly from a syntax perspective. 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? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
