Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 8BDA0C7DB11 for ; Mon, 19 Mar 2012 13:53:46 -0300 (ADT) Received: from mailout-de.gmx.net ([213.165.64.22]) by magus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1S9fq3-0003Po-UQ for pgsql-hackers@postgresql.org; Mon, 19 Mar 2012 16:53:45 +0000 Received: (qmail invoked by alias); 19 Mar 2012 16:53:29 -0000 Received: from a88-115-218-87.elisa-laajakaista.fi (EHLO [10.0.0.108]) [88.115.218.87] by mail.gmx.net (mp012) with SMTP; 19 Mar 2012 17:53:29 +0100 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX1/Xw9EpvNjXT9rIEiS8ar+TDDEDwUe2VgqmtvSJoJ rIBExdK9ExkOq0 Message-ID: <1332176001.8435.1.camel@vanquo.pezone.net> Subject: Re: Command Triggers, patch v11 From: Peter Eisentraut To: Tom Lane Cc: Andres Freund , pgsql-hackers@postgresql.org, Thom Brown , Dimitri Fontaine Date: Mon, 19 Mar 2012 18:53:21 +0200 In-Reply-To: <24506.1332119786@sss.pgh.pa.us> References: <201203162237.38813.andres@anarazel.de> <21818.1331934775@sss.pgh.pa.us> <201203162317.43818.andres@anarazel.de> <7094.1331996567@sss.pgh.pa.us> <9503.1332006327@sss.pgh.pa.us> <24814.1332021870@sss.pgh.pa.us> <1332107267.6915.2.camel@vanquo.pezone.net> <24506.1332119786@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2-1 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Y-GMX-Trusted: 0 X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/1227 X-Sequence-Number: 205109 On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote: > If we were going to change the output at all, I would vote for "CREATE > TABLE nnnn" so as to preserve the rowcount functionality. Keep in > mind though that this would force client-side changes, for instance in > libpq's PQcmdTuples(). Fixing that one routine isn't so painful, but > what of other client-side libraries, not to mention applications? Doesn't seem worth it to me. At least, "SELECT nnnn" makes some sense: nnnn rows were selected. "CREATE TABLE nnnn" means what? nnnn tables were created? What might make sense is to delegate this additional information to separate fields in a future protocol revision.