On Sun, Oct 16, 2011 at 8:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> 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 LOCAL isn't always what you want; per-transaction is not the same
>> as per-query, and multi-command query strings have funny semantics,
>> and multiple server round-trips are frequently undesirable; and it
>> just seems cleaner, at least IMHO.
>
> Well, syntax aside, the real issue here is that GUC doesn't have
> any notion of a statement-lifespan setting, and adding one would require
> adding per-statement overhead; not to mention possibly adding
> considerable logical complexity, depending on exactly what you wanted to
> define as a "statement". I don't think an adequate case has been
> made that SET LOCAL is insufficient.
Would it require adding per-statement overhead in every case, or just
when the feature gets used? I suspect the latter, which is no
different from anything else we have. We do already have at least one
other case that seems similar to me: you can apply a setting using
ALTER FUNCTION .. SET; the new value is applied when you enter the
function and restored on exit. I'd imagine that this would have
similar semantics. In terms of what qualifies as a statement, I would
rather imagine that it would only be worthwhile to apply this to
queries rather than fooling around with utility statements. I mean,
it would be nice if it Just Worked Anywhere, but that's likely to be a
lot more work (and grammar conflicts) than we want to deal with.
Anyway, the judgement of whether or not SET LOCAL is sufficient is in
the end a value judgement, and I'm not going to pretend that my
opinion is superior to all others. My personal experience, however,
is that I've never used or wanted SET LOCAL, but I've wanted a
single-statement equivalent a few times. So for me personally, having
this in lieu of SET LOCAL would be an improvement from a usability
perspective. YMMV, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company