Skip site navigation (1) Skip section navigation (2)

Re: proposal: set GUC variables for single query

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: set GUC variables for single query
Date: 2011-10-16 15:57:06
Message-ID: 4E9AFED2.5070200@wulczer.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On 16/10/11 17:49, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> 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 LOCAL cover this use-case pretty well already?

It does to a certain degree. If you have a bunch of statements in a
transaction and want to execute one of them with a different timezone
setting, you have to do the SET/RESET dance. In theory you should also
first grab the current value to set it back afterwards, in case someone
else did SET LOCAL before you, but I'll admin that's far-fetched.

The main use case would be apps running behing pgbouncer and using
statement pooling, and plain convenience.

I'd find it useful myself, but for now I'm making do with SET LOCAL and
it works fine. I'm bringing it up because it appears in the TODO created
at the PL Summit:

* Further discussion of per-statement config parameters for things
like timezone - Jan Urbanski

Tryin' to do my bit and all ;)

Jan

In response to

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-10-16 16:10:51
Subject: Re: Pushing ScalarArrayOpExpr support into the btree index AM
Previous:From: Thom BrownDate: 2011-10-16 15:50:57
Subject: Re: proposal: set GUC variables for single query

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group