Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
От | Hiroshi Inoue |
---|---|
Тема | Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |
Дата | |
Msg-id | 39F8FD85.B99A99A0@tpf.co.jp обсуждение исходный текст |
Ответ на | pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) (Tom Lane <tgl@postgresql.org>) |
Ответы |
Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
|
Список | pgsql-committers |
Tom Lane wrote: > Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > How would be the behavior of the following command sequence ? > > > begin; > > declare myc cursor for select * from t1 limit 1; > > fetch in myc; > > fetch in myc; > > > Could the last fetch return a row ? > > As the code now stands, the second fetch would return nothing. > I think this is clearly what any reasonable person would expect > given the LIMIT 1 clause. > Different from ordinary select statements we could gain the same result in case of cursors. begin; declare myc cursor for select * from t1; fetch in myc; For exaple, begin; declare myc cursor for select * from t1 limit all; fetch 20 in myc; (the first page) ...(interaction) fetch 20 in myc; (the next page) ..(interaction) fetch backward 20 in myc; (the previous page) ... What I expect here is to get rows of each page in an average response time not the total throughput of db operation. Regards, Hiroshi Inoue > > LIMIT ALL is a different story, because there's no semantic difference > between writing LIMIT ALL and writing no limit clause at all. We have > the option to create a distinction for planning purposes, however. > Question is do we need one? > > regards, tom lane
В списке pgsql-committers по дате отправления: