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 0317B475461 for ; Mon, 17 Mar 2003 19:40:45 -0500 (EST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id h2I0edq02693; Mon, 17 Mar 2003 19:40:39 -0500 (EST) From: Bruce Momjian Message-Id: <200303180040.h2I0edq02693@candle.pha.pa.us> Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign In-Reply-To: To: Peter Eisentraut Date: Mon, 17 Mar 2003 19:40:39 -0500 (EST) Cc: 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/687 X-Sequence-Number: 36933 Peter Eisentraut wrote: > Tom Lane writes: > > > * Backend's ReadyForQuery message (Z message) should carry an indication > > of current transaction status (idle/in transaction/in aborted transaction) > > so that frontend need not guess at state. Perhaps also indicate > > autocommit status. > > If we do this, could we get rid of the messy autocommit GUC option and > handle autocommit in the client? Before sending a command, the client > could check the transaction status and automatically choose to start a new > transaction. That way we could get rid of the current mess that every > client needs to send a SET autocommit command before it can safely do > anything. What if folks want all their connections autocommit off. Seems it is best in the server. -- 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