Message-ID: <3F694B06.3050802@klaster.net>
Date: Thu, 18 Sep 2003 08:04:54 +0200
From: Tomasz Myrta <jasiek@klaster.net>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; pl-PL;
	rv:1.5a) Gecko/20030718
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Lista dyskusyjna pgsql-sql <pgsql-sql@postgresql.org>
Subject: Re: cursors in plpgsql
References: <3F68C810.6020401@klaster.net> <5920.1063833193@sss.pgh.pa.us>
In-Reply-To: <5920.1063833193@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> Releases before 7.4 are spotty about supporting backwards scan of
> complex queries --- if you have a join or aggregate in the query,
> it likely won't work, yielding either strange errors or wrong answers.
> 
> It will work if the top plan node in the query is a SORT, though, so
> a possible workaround is to add an explicit ORDER BY to the cursor's
> query.  (You will need to do some investigation with EXPLAIN to make
> sure you are getting a suitable plan for the cursor.)
I rewrote my query to have sort in top of plan:
Sort  (cost=151.24..151.25 rows=1 width=36)
    Sort Key: czas
    ->  Aggregate  (cost=151.22..151.23 rows=1 width=36)
          ->  Group  (cost=151.22..151.23 rows=1 width=36)
                ->  Sort  (cost=151.22..151.22 rows=1 width=36)
I'm not sure if it is what you were talking about, but it didn't help.

Anyway the best choice for this function would be a C function, but SPI 
scares me...

And one more question - which syntax is valid?
move backward..
or
execute ''move backward...


> Or try 7.4 beta ...
Currently stable branches are better for me...
> 
> 			regards, tom lane
Regards,
Tomasz Myrta