Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I notice that cube_2.out hasn't been updated. Was that intentional? > Well, I was going to wait to see a buildfarm member that needed the > alternative exponent representation, and use the regression diff as a > template I've had

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Maybe we need to try to stress test the comparison routines a bit to make sure they really are deterministic. Eyeball inspection shows that cube_cmp is wrong: it's doing PG_RETURN_INT16 where it should say PG_RETURN_INT32.

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Maybe we need to try to stress test the comparison routines a bit to > make sure they really are deterministic. Eyeball inspection shows that cube_cmp is wrong: it's doing PG_RETURN_INT16 where it should say PG_RETURN_INT32. As best I can tell, the co

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Andrew Dunstan
Joshua Reich wrote: I just updated to the latest HEAD, so I assume I have the cube_1.out that you changed. If you look at the order of the results expected in cube.out and cube_1.out, they are different. So I don't think we have a problem with the code, we just need to fix the ordering in cube

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Joshua Reich
I just updated to the latest HEAD, so I assume I have the cube_1.out that you changed. If you look at the order of the results expected in cube.out and cube_1.out, they are different. So I don't think we have a problem with the code, we just need to fix the ordering in cube_1.out. The same pro

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc

2006-07-27 Thread Andrew Dunstan
Indeed. I am going to revert it. The trouble is we currently have several orthogonal variations, which is a worry on its own: . negative zero . exponent format, and . result ordering Looking closer, the result ordering certainly does seem odd, as you say. Surely with ORDER BY it should be d

Re: [HACKERS] [COMMITTERS] pgsql: another try at keeping AIX/ppc happy on cube test.

2006-07-27 Thread Rocco Altier
I think this will cause breakage for other people. Right now I think the order is unique to AIX for some reason. Recent buildfarm run of gazelle should have matched the -0 variant (cube_1.out), but did not. Also, what is worrisome is that there is an ORDER BY on the result set that is failing on