=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 17/10/11 02:53, Robert Haas wrote:
>> 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
On 17/10/11 02:53, Robert Haas wrote:
> On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane wrote:
>> Dimitri Fontaine writes:
>>> Now that you mention it, the following might actually already work:
>>
>>> WITH settings AS (
>>>SELECT set_config('timezone', 'Europe/Amsterdam', t),
>>> set_co
On Sun, Oct 16, 2011 at 8:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> I previously floated the idea of using a new keyword, possibly LET,
>> for this, like this:
>
>> LET var = value [, ...] IN query
>
>> I'm not sure if anyone bought it, but I'll run it up the flagpole
>> again and see if an
On 10/16/2011 08:59 PM, Tom Lane wrote:
Robert Haas writes:
I previously floated the idea of using a new keyword, possibly LET,
for this, like this:
LET var = value [, ...] IN query
I'm not sure if anyone bought it, but I'll run it up the flagpole
again and see if anyone salutes. I tend to a
Robert Haas writes:
> I previously floated the idea of using a new keyword, possibly LET,
> for this, like this:
> LET var = value [, ...] IN query
> I'm not sure if anyone bought it, but I'll run it up the flagpole
> again and see if anyone salutes. I tend to agree with the idea that
> SET LOC
On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane wrote:
> Dimitri Fontaine 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)
>> ),
>> fo
Dimitri Fontaine 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 * FRO
Tom Lane writes:
> That looks pretty non-future-proof to me. WITH is a SQL-standard
> syntax, it's not an extension that we control.
Now that you mention it, the following might actually already work:
WITH settings AS (
SELECT set_config('timezone', 'Europe/Amsterdam', t),
set_con
Dimitri Fontaine writes:
> I think it would fit quite well within our extending of the WITH syntax.
> WITH
> work_mem = '1GB',
> timezone = 'Europe/Amsterdam',
> foo AS (
> SELECT something
> )
> SELECT toplevel FROM foo;
That looks pretty non-future-proof to me. WITH is a SQL-standar
Jan Urbański writes:
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated. By "setting them back" I mean res
On 16/10/11 17:49, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> this idea has cropped up last PGCon - the ability to set GUC variables
>> for the duration of a single query. It would work by setting the GUCs
>> for the duration of the query and setting them back to what they were
On 16 October 2011 16:44, Jan Urbański wrote:
> Hi,
>
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated.
Doesn't SET
Hi,
this idea has cropped up last PGCon - the ability to set GUC variables
for the duration of a single query. It would work by setting the GUCs
for the duration of the query and setting them back to what they were
after it has terminated. By "setting them back" I mean respecting the
previously se
14 matches
Mail list logo