cdr_adaptive_odbc BUG ASTERISK-12275

My asterisk version is mentioned below.

asterisk-1.8.7.1-1.el6.x86_64
asterisk-odbc-1.8.7.1-1.el6.x86_64
I am using CentOS 6 64-bit.

I think I am hit by bug issues.asterisk.org/jira/browse/ASTERISK-12275

-- Reloading module 'cdr_adaptive_odbc.so' (Adaptive ODBC CDR backend) == Parsing '/etc/asterisk/cdr_adaptive_odbc.conf': == Found -- Found adaptive CDR table cdr@asterisk. > Found id column with type -5 with len 19, octetlen 19, and numlen (0,10) > Found accountcode column with type 12 with len 20, octetlen 120, and numlen (0,0) > Found src column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found dst column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found dcontext column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found clid column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found channel column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found dstchannel column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found lastapp column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found lastdata column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found start column with type 93 with len 19, octetlen 19, and numlen (0,0) > Found answer column with type 93 with len 19, octetlen 19, and numlen (0,0) > Found end column with type 93 with len 19, octetlen 19, and numlen (0,0) > Found duration column with type 4 with len 10, octetlen 10, and numlen (0,10) > Found billsec column with type 4 with len 10, octetlen 10, and numlen (0,10) > Found disposition column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found amaflags column with type 12 with len 80, octetlen 255, and numlen (0,0) > Found uniqueid column with type 12 with len 32, octetlen 192, and numlen (0,0) > Found userfield column with type 12 with len 255, octetlen 255, and numlen (0,0)

First I tried using MySQL but because of buggy mysql odbc connecter I could not make it run. I switched to PostgreSQL and now this.

If I see it correctly in Jira, this bug was resolved in 29/Jun/08 and as per changelog my version was built on 2011-09-23.

So, is this bug still alive or I am doing something silly.

For now I have used following alias.