X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (mx2.hub.org [200.46.204.254]) by postgresql.org (Postfix) with ESMTP id 1F05D11F6212 for ; Thu, 13 Apr 2006 17:26:52 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, SPF_SOFTFAIL=1.384] Received: from postgresql.org ([200.46.204.71]) by localhost (mx2.hub.org [200.46.204.254]) (amavisd-new, port 10024) with ESMTP id qgDT8+VHH3bg for ; Thu, 13 Apr 2006 17:26:46 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id CDA8811F61F1 for ; Thu, 13 Apr 2006 17:26:44 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1FU8Ob-0003gT-00; Thu, 13 Apr 2006 16:26:29 -0400 To: Tom Lane Cc: Greg Stark , Stephen Frost , Martijn van Oosterhout , Dave Page , pgsql-hackers@postgresql.org, Hiroshi Inoue Subject: Re: Practical impediment to supporting multiple SSL libraries References: <20060413113405.GF7362@svana.org> <87ek01ik26.fsf@stark.xeocode.com> <20060413153336.GT4474@ns.snowman.net> <20666.1144943798@sss.pgh.pa.us> <20060413160903.GV4474@ns.snowman.net> <20970.1144946185@sss.pgh.pa.us> <87u08xgyvd.fsf@stark.xeocode.com> <28809.1144952227@sss.pgh.pa.us> In-Reply-To: <28809.1144952227@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 13 Apr 2006 16:26:28 -0400 Message-ID: <87odz5gr2j.fsf@stark.xeocode.com> Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Archive-Number: 200604/524 X-Sequence-Number: 82247 Tom Lane writes: > Greg Stark writes: > > I think there's some confusion about what problem this is aiming to solve. I > > thought the primary problem ODBC and other drivers have is just that they want > > to be able to fetch whatever records are available instead of waiting for the > > entire query results to be ready. > > No, that's not what I'm thinking about at all, and I don't think Martijn > is either. The point here is that ODBC wants to store the resultset in > a considerably different format from what libpq natively provides, and > we'd like to avoid the conversion overhead. So how would you provide the data to the callback? And how does having a callback instead of a regular downcall give you any more flexibility in how you present the data? -- greg