Re: Regression test failures on big endian - Mailing list pgsql-odbc
| From | Christoph Berg |
|---|---|
| Subject | Re: Regression test failures on big endian |
| Date | |
| Msg-id | 20160402220602.GB2042@msg.df7cb.de Whole thread Raw |
| In response to | Regression test failures on big endian (Christoph Berg <myon@debian.org>) |
| Responses |
Re: Regression test failures on big endian
("Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>)
|
| List | pgsql-odbc |
Re: To PostgreSQL ODBC 2016-03-18 <20160318211558.GA7269@msg.df7cb.de> > Hi, > > 09.05.0100 is failing the result-conversions tests on big endian > architectures, e.g. powerpc: > > https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=powerpc&ver=1%3A09.05.0100-1&stamp=1458326445 Hi again, these failures are preventing psqlodbc from entering the next Debian release, and hence are critical. Can anybody with more insight comment if the differences seen are real problems or just cosmetic variations? In that case I could add more _1.out files to catch them. > * expected/result-conversions.out Sun Jan 10 13:25:15 2016 > --- results/result-conversions.out Fri Mar 18 18:40:34 2016 > *************** > *** 262,270 **** > '1234567' (int4) as SQL_C_UTINYINT: 135 > '1234567' (int4) as SQL_C_SBIGINT: 1234567 > '1234567' (int4) as SQL_C_UBIGINT: 1234567 > ! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200 > '1234567' (int4) as SQL_C_BOOKMARK: 1234567 > ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 87D61200 > '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 > '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 > '1234567' (int4) as SQL_C_GUID: SQLGetData failed > --- 262,270 ---- > '1234567' (int4) as SQL_C_UTINYINT: 135 > '1234567' (int4) as SQL_C_SBIGINT: 1234567 > '1234567' (int4) as SQL_C_UBIGINT: 1234567 > ! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687 > '1234567' (int4) as SQL_C_BOOKMARK: 1234567 > ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 0012D687 > '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 > '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 > '1234567' (int4) as SQL_C_GUID: SQLGetData failed > *************** > *** 1328,1334 **** > 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) > 'foobar' (text) as SQL_C_WCHAR: foobar > '' (text) as SQL_C_CHAR: > ! '' (text) as SQL_C_WCHAR: \FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) > '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) > 'NaN' (float4) as SQL_C_FLOAT: nan > --- 1328,1334 ---- > 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) > 'foobar' (text) as SQL_C_WCHAR: foobar > '' (text) as SQL_C_CHAR: > ! '' (text) as SQL_C_WCHAR: \ FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) > '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) > 'NaN' (float4) as SQL_C_FLOAT: nan > > > The failure pattern is always the same: > https://buildd.debian.org/status/package.php?p=psqlodbc > > (There is an extra problem with bulkoperations on sparc64, but that > might be a problem with that port. > https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-1&stamp=1458326750 > ) Christoph
pgsql-odbc by date: