X-Original-To: pgsql-interfaces@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id B9593475ED4 for ; Thu, 10 Apr 2003 18:14:47 -0400 (EDT) Received: from localhost.localdomain (m066-156.nv.iinet.net.au [203.217.66.156]) by postgresql.org (Postfix) with ESMTP id D8464475EDF for ; Thu, 10 Apr 2003 18:14:45 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h3AMElWV001500 for ; Fri, 11 Apr 2003 08:14:47 +1000 Subject: Re: [HACKERS] More thoughts about FE/BE protocol From: Bruce Badger To: pgsql-interfaces@postgresql.org In-Reply-To: <5564.1049998513@sss.pgh.pa.us> References: <10478.1049927451@sss.pgh.pa.us> <3E95A3CD.9080500@xythos.com> <5564.1049998513@sss.pgh.pa.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 11 Apr 2003 08:14:46 +1000 Message-Id: <1050012887.1063.12.camel@alice> Mime-Version: 1.0 X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/73 X-Sequence-Number: 4012 On Fri, 2003-04-11 at 04:15, Tom Lane wrote: > Well, as far as network roundtrips go, it's always been true that you > don't really have to wait for the backend's response before sending the > next command. The proposal to decouple SYNC from individual commands > should make this easier: you fire off N commands "blind", then a SYNC. > When the sync response comes back, it's done. If any of the commands > fail, all else up to the SYNC will be ignored, so you don't have the > problem of commands executing against an unexpected state. Is SYNC going to be a new kind of message? Is the SYNC response yet another? Either way, could this be used as a keep-alive for long-lived connections? (some users of the current Smalltalk drivers report that long lived connections over the Internet sometimes just die) Also, with the new protocol, will the number of affected rows be returned in a way that does not require parsing to fish it out? Thanks, Bruce