| Re: paging bug for postgresql [message #8548 is a reply to message #8539] |
Fri, 07 February 2003 07:09   |
laser
Messages: 9
Registered: January 2003
Karma:
|
Junior Member |
|
|
if I understood correctly,
(pos - (ceil(pos/40)-1)*40)
wants to calcuate the position of threads in one page,
but ceil() function in postgresql return numeric type,
that is, a accurate float point number, so, if you do:
ceil(1/40), you'll get 0 as return, but if you do:
ceil(1/40.0), you'll get 1 as return, and the later is what
you expect, think about this scenario:
you post 40 thread continusly, no reply, just post 40 new
thread, then, if we use ceil(pos/40) the 40th thread would
calculate the 'pos' cloumn value:
40 - (ceil(40/40)-1)*40 = 40,
it's right, but for those pos < 40 threads, for example, the No. 1 thread, the result would be:
1 - (ceil(1/40)-1)*40 = 41
here ceil(1/40) = 0
and other < 40 threads are alike.
so, the sorting of threads would show as below:
40th,
1st,
2nd,
...
39th,
that's what I get in my environment. and it would appeared every 40 threads.
now if we use ceil(pos/40.0), then the above would sort correctly.
for sure, you may use type coerce to avoid this kind of problem,
like:
ceil(pos::numeric/40::numeric), (or ::float)
it would give you expect result, and thus you may use
global setting THREADS_PER_PAGE as well -- that's what I guess
why the setting not being used in pgsql's code, becaues you need
to add a '.0' behind THREADS_PER_PAGE to coerce it to numeric type but that's difficult for a variable.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]