X-Original-To: pgsql-hackers@postgresql.org Received: from candle.pha.pa.us (momjian.navpoint.com [207.106.42.251]) by postgresql.org (Postfix) with ESMTP id 7C7444758E6 for ; Tue, 18 Mar 2003 19:55:01 -0500 (EST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id h2J0sgd10636; Tue, 18 Mar 2003 19:54:42 -0500 (EST) From: Bruce Momjian Message-Id: <200303190054.h2J0sgd10636@candle.pha.pa.us> Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign In-Reply-To: <20030318231549.GB2577@dcc.uchile.cl> To: Alvaro Herrera Date: Tue, 18 Mar 2003 19:54:41 -0500 (EST) Cc: Peter Eisentraut , Tom Lane , PostgreSQL Development X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200303/744 X-Sequence-Number: 36990 Alvaro Herrera wrote: > On Tue, Mar 18, 2003 at 05:18:02PM -0500, Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > > > What if folks want all their connections autocommit off. > > > > > > For interactive use, people can record their preferred setting in > > > ~/.psqlrc or something like that. > > > > But that only works for psql, right? How would this be done at the > > libpq level? Environment variables? GUC seems a whole lot cleaner. > > I think an environment variable would be right. The current method is > not clean in the sense that a client cannot decide what she wants; she > just accepts the decision from the DBA. Thus, an application can't be > written with a certain value in mind, because the DBA can change the > setting at any time. The client can say "SET autocommit to off" or on. It can use SHOW to to see the setting. Environment variables are used mostly for connecting, and once connected, we use GUC. In fact, an environment variable seems wrong because it isn't integrated into the client, like a SET command is. > Client-side decision is the wiser proposal, I think. > > > I understand. I just don't see any value in pushing that logic into > > each client when we can do it centrally in the server. > > The server doesn't know beforehand what the client wants. True, but GUC seems like the way to go, and we have per-user/db settings for GUC. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073