Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 5D3169FA66C for ; Fri, 19 Jan 2007 09:15:29 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 31311-02 for ; Fri, 19 Jan 2007 09:15:06 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by postgresql.org (Postfix) with ESMTP id B541E9FA667 for ; Fri, 19 Jan 2007 09:15:16 -0400 (AST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7ta8-0007f4-Ln for pgsql-sql@postgresql.org; Fri, 19 Jan 2007 14:15:00 +0100 Received: from pc035-72.amg.gda.pl ([153.19.72.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 14:15:00 +0100 Received: from mstepnicki by pc035-72.amg.gda.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 14:15:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: =?iso-8859-2?q?Marcin_St=EApnicki?= Subject: Re: Postgresql & Oracle Heteregenous services - strange behaviour Date: Fri, 19 Jan 2007 14:14:26 +0100 Organization: Linux.PL Lines: 28 Message-ID: References: <20070117125857.GD19527@phlogiston.dyndns.org> <45AE1EDC.7090005@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pc035-72.amg.gda.pl User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.668 tagged_above=0 required=5 tests=AWL, BAYES_50, INFO_TLD, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200701/79 X-Sequence-Number: 27231 Dnia Wed, 17 Jan 2007 13:04:28 +0000, Richard Huxton napisał(a): > That'd be my guess. And then it's not fetching any rows, expecting > cursor-like behaviour. Of course we fetch all the rows before returning > any results. > > The real solution would be to add "LIMIT 0" or "LIMIT 1" to the > column-finding query, but I doubt that's possible with the Oracle plugin. > > Perhaps check if there's a "fetch N rows at a time" option for the ODBC > setup that might help you. I've tried various settings, upgraded to psqlodbc 8.02.0200, looked into the source (info.c, retry_public_schema label) and there's a query which gets the columns (select n.nspname, c.relname, a.attname, a.atttypid (...)), I now can even see it in logs but there's still this additional select before. I think it's not psqlodbc problem, because when I issue my queries directly from isql from unixodbc everything seems normal - I get this additional select only when quering from Oracle using @my_server. Therefore, I think it is Oracle's fault and try to move this topic to Metalink. Thank you again. -- | And Do What You Will be the challenge | http://apcoln.linuxpl.org | So be it in love that harms none | http://biznes.linux.pl | For this is the only commandment. | http://www.juanperon.info `---* JID: Aragorn_Vime@jabber.org *---' http://www.naszedzieci.org