Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ePAi4-0005rA-2f for pgsql-docs@arkaria.postgresql.org; Wed, 13 Dec 2017 17:20:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ePAi3-0001ZP-1F for pgsql-docs@arkaria.postgresql.org; Wed, 13 Dec 2017 17:20:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ePAi2-0001ZD-OY for pgsql-docs@lists.postgresql.org; Wed, 13 Dec 2017 17:20:42 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ePAhv-00047y-J9 for pgsql-docs@postgresql.org; Wed, 13 Dec 2017 17:20:41 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AF80F20997; Wed, 13 Dec 2017 12:20:34 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 13 Dec 2017 12:20:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9DROtA 1HDLTUkHa2HZJjHtILI8sr78PQGHDEsY23v9A=; b=dxIQNabFDzqjuSvYdsn9Id XkydMKJ6tl4hlBHFcY8KNu+qucFnTV/cOiNu6hthGDuh3Ynbu9bBQ5zKVeo3mrPo QAahuF3DOC0fIEHnsuV5v5ez8hLa5MobEf0LeMxa+gTFCet2kU6Av1RksVXfagqB +JoYwq44mXjflKCaeDMJbSrNj+c5qt2aiiUeAr3DHmi1M3plFIcIu7xTR3ulnIKb 6S7azv0gSF43ylomWTVLbLDmMbhAxwh8eBTOOyT4PQZZLIJAUEtVhHXhIzUOhikO 5UO3lnnEIq3r/2K6cRXlGoLBofTa1rowaASLr1TyS6CWAlG73K5LVdMCvf2euenw == X-ME-Sender: Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 59DA624600; Wed, 13 Dec 2017 12:20:34 -0500 (EST) Subject: Re: Is PQgetResult() guaranteed to return the whole SQL command result? To: Arseny Sher , pgsql-docs@postgresql.org References: <87o9n2hh30.fsf@ars-thinkpad> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Wed, 13 Dec 2017 12:20:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87o9n2hh30.fsf@ars-thinkpad> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/13/17 08:50, Arseny Sher wrote: > I wonder is it guaranteed that one PQgetResult() call returns result for > the whole one statement (SQL command) in usual (not SingleRow) mode? > For instance, if I run PQsendQuery with query consisting of two > statements (separated by semicolons), is possible to have three or more > PQgetResult calls returning data? I guess not, but it seems to be not > clear from the docs. > > PQgetResult description says: > > Waits for the next result from a prior call... > > Does one "result" here correspond to one statement? If you PQsendQuery() a string consisting of multiple statements (e.g., "SELECT 1; SELECT 2;"), you will have to call PQgetResult() twice to get two result sets. The third call will return NULL indicating that there are not more result sets. Are you asking whether it is possible that the results for the two statements might be split across more than two libpq result sets? That is not possible. But there is a possible future feature that a single command could produce more than one result set. So it is not necessarily the case that the number of statements equals the number of result sets. But the relationship should always be deterministic. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services