Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZdmn-0004CQ-B6 for pgsql-interfaces@arkaria.postgresql.org; Mon, 14 Apr 2014 10:06:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WZdml-0004hr-N1 for pgsql-interfaces@arkaria.postgresql.org; Mon, 14 Apr 2014 10:06:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZdml-0004hl-3L for pgsql-interfaces@postgresql.org; Mon, 14 Apr 2014 10:06:43 +0000 Received: from mail231.strasbourg.4js.com ([92.103.31.231]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZdmj-0005fS-1E for pgsql-interfaces@postgresql.org; Mon, 14 Apr 2014 10:06:42 +0000 Received: from [10.0.40.29] (orion.strasbourg.4js.com [10.0.40.29]) (authenticated bits=0) by mail231.strasbourg.4js.com (8.14.4/8.14.4/Debian-4) with ESMTP id s3EA6dkk031295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:06:39 +0200 Message-ID: <534BB32F.4020503@4js.com> Date: Mon, 14 Apr 2014 12:06:39 +0200 From: Sebastien FLAESCH Organization: Four Js Development Tools User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: pgsql-interfaces@postgresql.org Subject: Type identification with libpq / PQFmod() when using aggregates (SUM) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail231 X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail231.strasbourg.4js.com [10.10.0.1]); Mon, 14 Apr 2014 12:06:39 +0200 (CEST) X-Pg-Spam-Score: -2.9 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-interfaces Precedence: bulk Sender: pgsql-interfaces-owner@postgresql.org Hello, In a libpq client application, we need to properly identify the data type when fetching data produced from a SELECT, therefore we use the PQftype() and PQfmod() APIs ... Consider a column defined with the following data type: interval hour to second(0) When executing a SELECT query using directly the columns values (no aggregate), the libpq APIs (PQftype and PQfmod) return clear type information. With an interval hour to second(0), we get: PQftype() = 1186 PQfmode() = 469762048 (pgprec=7168, pgscal=65532, pgleng=469762044) where precision, scale and length are computed as follows: #define VARHDRSZ 4 int pgfmod = PQfmod(st->pgResult, i); int pgprec = (pgfmod >> 16); int pgscal = ((pgfmod - VARHDRSZ) & 0xffff); int pgleng = (pgfmod - VARHDRSZ); But when using an aggregate function like SUM(), PQfmode() function returns "no information available" (-1) ... Is the type of the result of an aggregate function (or even more complex expressions) not known by the server? Is this considered as bug or is it expected? I found not much information in the PQfmod() description. A workaround is to cast the result of the aggregate function: SELECT CAST( SUM(mycol) AS INTERVAL HOUR TO SECOND(0) ) FROM ... But I just wonder that the type of the result is not just the same as the type of the source column... Thanks! Seb -- Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-interfaces