| paging bug for postgresql [message #8531] |
Wed, 05 February 2003 17:04  |
laser
Messages: 9
Registered: January 2003
Karma: 0
|
Junior Member |
|
|
in $FUDFORUM/install/forum_data/src/th.inc.t,
around line 322:
(pos-(CEIL(pos/40)-1)*40)
should be
(pos-(CEIL(pos/40.0)-1)*40)
I think.
and, for postgresql,
ceil(pos/40::float) is the equivalance of
ceil(pos/40.0)
I think it's not good to hard code the THREADS_PER_PAGE in pgsql
code.
thanks
|
|
|
|
|
|
| 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: 0
|
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.
|
|
|
|
| Re: paging bug for postgresql [message #8628 is a reply to message #8548] |
Tue, 11 February 2003 21:30 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Fixed in CVS, thank you for the detailed information. Another bug was fixed in the same code, the hardcoded number 40 should've been a dynamic variable, that also has been fixed.
FUDforum Core Developer
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]