Re: Vote totals for SET in aborted transaction
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Lockhart <lockhart@fourpalms.org>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Hannu Krosing <hannu@tm.ee>, Scott Marlowe <scott.marlowe@ihs.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-04-29T16:20:07Z
Lists: pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.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