Обсуждение: COLUMN_SIZE for bytea now equals -4 (09.05 vs 09.06)
Hi, I noticed Ubuntu 12.04 package odbc-postgresql updated from 09.05.0400 to 09.06.0200. Since then, a 'bytea` column info obtained with SQLColumns no longer reports COLUMN_SIZE larger than 0, but equal to -4. AFAIU, -4 means SQL_NO_TOTAL. Which change in the release notes corresponds to that? https://odbc.postgresql.org/docs/release.html Is it this one? 18. Change the default of ByteaAsLongVarBinary from 0 to 1 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2017/03/28 21:37, Mateusz Loskot wrote: > Hi, > > I noticed Ubuntu 12.04 package odbc-postgresql updated > from 09.05.0400 to 09.06.0200. > > Since then, a 'bytea` column info obtained with SQLColumns > no longer reports COLUMN_SIZE larger than 0, but equal to -4. > AFAIU, -4 means SQL_NO_TOTAL. > > Which change in the release notes corresponds to that? > https://odbc.postgresql.org/docs/release.html > > Is it this one? > > 18. Change the default of ByteaAsLongVarBinary from 0 to 1 Yes. Is it inconvenient to you? regards, Hiroshi Inoue
On 28 March 2017 at 16:30, Inoue, Hiroshi <h-inoue@dream.email.ne.jp> wrote: > On 2017/03/28 21:37, Mateusz Loskot wrote: >> >> I noticed Ubuntu 12.04 package odbc-postgresql updated >> from 09.05.0400 to 09.06.0200. >> >> Since then, a 'bytea` column info obtained with SQLColumns >> no longer reports COLUMN_SIZE larger than 0, but equal to -4. >> AFAIU, -4 means SQL_NO_TOTAL. >> >> Which change in the release notes corresponds to that? >> https://odbc.postgresql.org/docs/release.html >> >> Is it this one? >> >> 18. Change the default of ByteaAsLongVarBinary from 0 to 1 > > > Yes. Thanks for the confirmation. > Is it inconvenient to you? Although one may consider it as a behaviour braking change, no it is not inconvenient to me. It's just that CI tests of nanodbc library suddenly yet mysterious started failing on Travis CI. Turns out it is due to Ubuntu package odbc-postgresql bumped from 09.05.0400 to 09.06.0200 there. Details at https://github.com/lexicalunit/nanodbc/issues/249 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net