Обсуждение: Bug #520: Bug in order by clausule part II

Sandor, Vig (sandor.vig@audi.hu) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
Bug in order by clausule part II

Long Description
Sorry, I forgot:
The select max(mit_id) from table
is also wrong! (At the specified range. see below)



I have made a table with a TableID called "mit_id" character(16) This column is filled as follows:
row 0: 0000000000000000
row 1: 0000000000000001
..
row 10: 0000000000000000A
..
row 35: 0000000000000000Z
row 36: 00000000000000010
row 37: 00000000000000011
...
etc...

now the sql command: select mit_id from table order by mit_id
should select all rows odered as the ABC. f.e.:123456789ABCD...QRST....etc.
At the range of 00000000000000C0...00000000000000CZ it goes creazy:
....
 00000000000000CP
 00000000000000CQ
 00000000000000CR
 00000000000000CT
 00000000000000CU
 00000000000000CV
 00000000000000CW
 00000000000000CX
 00000000000000CY
 00000000000000CS
 00000000000000CZ
 00000000000000D0
...
(The CS value after the CY?????) Before, and after it goes "normal", only at this
interval goes mad. I've tried Postgresql 7.0, and 7.1.3 the bug still exist under Red Hat 7.1 in two different
machines.I've tested under cygwin, there is NO SUCH BUG! 
At request I can send you the Database backup...

Sample Code


No file was uploaded with this report

On Fri, 2001-11-23 at 11:24, pgsql-bugs@postgresql.org wrote:
> now the sql command: select mit_id from table order by mit_id
> should select all rows odered as the ABC. f.e.:123456789ABCD...QRST....et=
c.
> At the range of 00000000000000C0...00000000000000CZ it goes creazy:
> ....
>  00000000000000CP
>  00000000000000CQ
>  00000000000000CR
>  00000000000000CT
>  00000000000000CU
>  00000000000000CV
>  00000000000000CW
>  00000000000000CX
>  00000000000000CY
>  00000000000000CS
>  00000000000000CZ
>  00000000000000D0
> ...
> (The CS value after the CY?????) Before, and after it goes "normal", only=
 at this
> interval goes mad. I've tried Postgresql 7.0, and 7.1.3 the bug still exi=
st under Red Hat 7.1 in two different machines. I've tested under cygwin, t=
here is NO SUCH BUG!
> At request I can send you the Database backup...=20

recreating the index on mit_id could help.

Markus Bertheau