Re: cursors in plpgsql
От | Tomasz Myrta |
---|---|
Тема | Re: cursors in plpgsql |
Дата | |
Msg-id | 3F694B06.3050802@klaster.net обсуждение исходный текст |
Ответ на | Re: cursors in plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-sql по дате отправления: