Re: proposal: set GUC variables for single query

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: set GUC variables for single query
Date: 2011-10-17 08:51:15
Message-ID: 4E9BEC83.5070603@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17/10/11 02:53, Robert Haas wrote:
> On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>>> Now that you mention it, the following might actually already work:
>>
>>> WITH settings AS (
>>> SELECT set_config('timezone', 'Europe/Amsterdam', t),
>>> set_config('work_mem', '1 GB', t)
>>> ),
>>> foo AS (
>>> SELECT …
>>> )
>>> INSERT INTO bar SELECT * FROM foo;
>>
>> Only for small values of "work" ... you won't be able to affect planner
>> settings that way, nor can you assume that that WITH item is executed
>> before all else. See recent thread pointing out that setting values
>> mid-query is unsafe.
>
> I previously floated the idea of using a new keyword, possibly LET,
> for this, like this:
>
> LET var = value [, ...] IN query

LET was something I thought about, although you'd have to use something
like parenthesis around the GUC assignements because "value" can contain
commas, leading to shift/reduce conflicts (that sucks, unfortunately).

But before whipping out the paint bucket I wanted to see if there's
enough buy-in to justify rehashing the syntax details.

Cheers,
Jan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-10-17 09:48:38 Re: Underspecified window queries in regression tests
Previous Message Yeb Havinga 2011-10-17 08:44:38 Re: [REVIEW] Patch for cursor calling with named parameters