X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E768E9DC83C for ; Sun, 8 Jan 2006 16:37:00 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 78616-09 for ; Sun, 8 Jan 2006 16:36:59 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from fep04.ttnet.net.tr (mail.ttnet.net.tr [212.175.13.129]) by postgresql.org (Postfix) with ESMTP id ACF739DC836 for ; Sun, 8 Jan 2006 16:36:50 -0400 (AST) Received: from alamut ([85.102.233.174]) by fep04.ttnet.net.tr with ESMTP id <20060108203402.IYSS1378.fep04.ttnet.net.tr@alamut> for ; Sun, 8 Jan 2006 22:34:02 +0200 Date: Sun, 8 Jan 2006 22:34:11 +0200 From: Volkan YAZICI To: pgsql-interfaces@postgresql.org Subject: Re: PQfformat() and Composite Formatted Results Message-ID: <20060108203411.GA11875@alamut> References: <20051230233709.GA771@alamut> <16194.1135986735@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16194.1135986735@sss.pgh.pa.us> User-Agent: Mutt/1.4.2.1i X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.985 required=5 tests=[AWL=-0.813, DNS_FROM_RFC_ABUSE=0.479, DNS_FROM_RFC_POST=1.44, DNS_FROM_RFC_WHOIS=0.879] X-Spam-Score: 1.985 X-Spam-Level: * X-Archive-Number: 200601/11 X-Sequence-Number: 5927 Hi, I've prepared a patch[1] which makes it possible to use composite formats in query results. It defines PQexecParams() PQexecPrepared() PQsendQueryParams() PQsendPrepared() functions with last int resultFormat parameter replaced with int nResFormat, const int resParamFormats Therefore, it breaks compatibility with the existing PQ*Params() and PQ*Prepared() functions. (Use at your own risk.) There's also a test case[2] too [1] http://www.students.itu.edu.tr/~yazicivo/libpq_res_fmt.patch [2] http://www.students.itu.edu.tr/~yazicivo/pg_res_fmt.c Any comments will be appreciated. Regards. On Dec 30 06:52, Tom Lane wrote: > It's not a protocol restriction, it's a libpq restriction made in the > name of keeping the API from getting too unwieldy. We could add more > entry points with different parameter lists to address this. I have > a feeling that refactoring the API of the query functions entirely > might be a better idea, though.