| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hannu Krosing <hannu(at)tm(dot)ee>, Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Vote totals for SET in aborted transaction |
| Date: | 2002-04-29 16:20:07 |
| Message-ID: | 24355.1020097207@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> Rather than dismissing this out of hand, try to look at what it *does*
> enable. It allows developers to tune specific queries without having to
> restore values afterwards. Values or settings which may change from
> version to version, so end up embedding time bombs into applications.
I think it's a great idea. I just want it to be a different syntax from
the existing SET, so as not to break existing applications that expect
SET to be persistent. It seems to me that marking such a command with
a new syntax is reasonable from a user-friendliness point of view too:
if you write "LOCAL SET foo" or some similar syntax, it is obvious to
every onlooker what your intentions are. If we redefine "SET" to have
context-dependent semantics, I think we are just creating a recipe for
confusion.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2002-04-29 16:27:10 | Re: Vote totals for SET in aborted transaction |
| Previous Message | Tom Lane | 2002-04-29 16:06:21 | Re: Vote totals for SET in aborted transaction |