X-Original-To: pgsql-hackers@postgresql.org Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 005E647580B for ; Fri, 21 Mar 2003 13:00:15 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.8/8.12.8) with ESMTP id h2LI08ub014167; Fri, 21 Mar 2003 13:00:08 -0500 (EST) To: Bruce Momjian Cc: Peter Eisentraut , Alvaro Herrera , PostgreSQL Development Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign In-reply-to: <200303211746.h2LHk2912957@candle.pha.pa.us> References: <200303211746.h2LHk2912957@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Fri, 21 Mar 2003 12:46:02 -0500" Date: Fri, 21 Mar 2003 13:00:07 -0500 Message-ID: <14166.1048269607@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200303/930 X-Sequence-Number: 37176 Bruce Momjian writes: > But isn't that like saying that the spec doesn't apply to libpq at all. > Why would autocommit not apply but other queries specification apply? No, you're missing the point. Essentially all the client libraries offer their own autocommit behavior on top of what the spec says. libpq is alone in not having any such client-side logic. So it's not a foregone conclusion that we should implement autocommit on/off logic on the server side as a substitute for adding it to libpq. We have now tried doing it on the server side, and we are finding that we don't like the side-effects; so it's time to revisit that decision. regards, tom lane