From: | Tomasz Myrta <jasiek(at)klaster(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Lista dyskusyjna pgsql-sql <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: cursors in plpgsql |
Date: | 2003-09-18 06:04:54 |
Message-ID: | 3F694B06.3050802@klaster.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | tom baker | 2003-09-18 18:11:41 | Re: transaction locking |
Previous Message | Stephan Szabo | 2003-09-18 05:33:15 | Re: transaction locking |