Marc,
Below is a message I just received and I'm wondering what's a problem of such delay ? 5 days is too much :)
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83---------- Forwarded message ----------
Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159])
by ra.sai.msu.su (8.12.10/8.12.10) with ESMTP id j1L6Mo5P012614;
Mon, 21 Feb 2005 09:22:50 +0300 (MSK)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by svr4.postgresql.org (Postfix) with ESMTP id 9264A5AFD51;
Mon, 21 Feb 2005 06:22:48 +0000 (GMT)
X-Original-To: [EMAIL PROTECTED]
Received: from localhost (unknown [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 3C73D8BA156
for <[EMAIL PROTECTED]>; Wed,
16 Feb 2005 20:35:42 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 47785-08
for <[EMAIL PROTECTED]>;
Wed, 16 Feb 2005 20:35:20 +0000 (GMT)
Received: from lnfm1.sai.msu.ru (lnfm1.sai.msu.ru [195.208.220.1])
by svr1.postgresql.org (Postfix) with ESMTP id 126A78B9EE3
for <pgsql-hackers@postgresql.org>; Wed, 16 Feb 2005 20:28:51 +0000 (GMT)
Received: from lnfm1.sai.msu.ru (localhost.localdomain [127.0.0.1])
by lnfm1.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1GKSjOg010158;
Wed, 16 Feb 2005 23:28:45 +0300
Received: from localhost ([EMAIL PROTECTED])
by lnfm1.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1GKSjaM010154;
Wed, 16 Feb 2005 23:28:45 +0300
X-Authentication-Warning: lnfm1.sai.msu.ru: math owned process doing -bs
Date: Wed, 16 Feb 2005 23:28:45 +0300 (MSK)
From: "Sergey E. Koposov" <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Strange RETURN NEXT behaviour in Postgres 8.0 In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=
X-Spam-Level: X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: [EMAIL PROTECTED]
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes: > LOOP > FETCH cur into rec; > RETURN NEXT rec; > EXIT WHEN NOT FOUND; > END LOOP; > RETURN;
Don't you think you should have the EXIT *above* the RETURN NEXT? I would expect this to emit a bogus row of nulls after the last row returned by the cursor. (At least that's what I get with current sources. Pre-8.0 it might return the last row twice.)
Yes, surely EXIT should be written before RETURN NEXT, it was my error,
(thanks, but I've found that error by myself, after posting my message) But that small bug does not affect the original problem.
Running it on a 500-million-row table would quite possibly run out of memory or disk space, too, because RETURN NEXT accumulates all the results before the function is actually exited.
Yes, that's right, but I did not waited until the whole table was loaded in the function. The error, which is the subject of current thread occured just immediately after "select * from yyy()", so surely was not caused by memory overfilling.
Concerning to the exact form of my functions (using cursors, but still
collecting all the data in the memory). As I understand this is the only one
way (or just the simplest way ???) to execute fully dynamic queries returned by C function in PL/SQL.
For the real functions which I use, instead of
query = ''SELECT * FROM usno'';
I have
query = my_C_function(some_args);
(see full code in my first message)
------------------------------------------------------------
Sergey E. Koposov
Sternberg Astronomical Institute, Moscow University (Russia)
Max-Planck Institute for Astronomy (Germany) Internet: [EMAIL PROTECTED], http://lnfm1.sai.msu.su/~math/
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
