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 D68F49DC83B for ; Fri, 30 Dec 2005 19:52:17 -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 75114-08 for ; Fri, 30 Dec 2005 19:52:19 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 24EF39DC812 for ; Fri, 30 Dec 2005 19:52:14 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jBUNqGQs016195; Fri, 30 Dec 2005 18:52:16 -0500 (EST) To: Volkan YAZICI cc: pgsql-interfaces@postgresql.org Subject: Re: PQfformat() and Composite Formatted Results In-reply-to: <20051230233709.GA771@alamut> References: <20051230233709.GA771@alamut> Comments: In-reply-to Volkan YAZICI message dated "Sat, 31 Dec 2005 01:37:10 +0200" Date: Fri, 30 Dec 2005 18:52:15 -0500 Message-ID: <16194.1135986735@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.055 required=5 tests=[AWL=0.055] X-Spam-Score: 0.055 X-Spam-Level: X-Archive-Number: 200512/48 X-Sequence-Number: 5916 Volkan YAZICI writes: > PQfformat() returns the format code indicating the format of the > given column. But, AFAIC, it's not possible to gather composite > formatted results using current query execution functions. They > only permit to specify the return format of the whole result > struct. (Like all of them will be binary or text.) Therefore, there > doesn't remain any usage difference between PQbinaryTuples() and > PQfformat(). > Please fix me if I'm wrong. Is this remained as a TODO for the > protocol or I missed something totally? 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. regards, tom lane