Hi, I recently upgraded DBD::Pg from version 1.49 (that came with Fedora Core 8) to 2.17.2. One of my programs uses the TYPE attribute of statements in exactly the way suggested in the DBI perldoc for type_info:
---- extract from http://search.cpan.org/~timb/DBI/DBI.pm#type_info ---- For example, to find the type name for the fields in a select statement you can do: @names = map { scalar $dbh->type_info($_)->{TYPE_NAME} } @{ $sth->{TYPE} } ------------------------------------------------------------------------ but this line stopped working for any statements where the results include a column of PostgreSQL type 'text'. The problem is caused by $sth->{TYPE} returning -1 for the text column, and then there being no type_info entry for that value. I searched around and found a thread in this list starting at message: http://www.nntp.perl.org/group/perl.dbd.pg/2007/08/msg162.html where Greg Sabino Mullane indicates that the change to returning -1 is intentional. Should there also be a type_info entry so that the code from the DBI documentation works? I also found there's at least one other person who has had the same problem: http://stackoverflow.com/questions/2562587/why-doesnt-dbi-dbdpg-return-the-correct-column-type-for-text-for-my-ad-hoc-q I now appreciate that $sth->{pg_type} offers a workaround, but I'd prefer it worked as suggested by the DBI docs if at all possible. Even if you'd prefer to not change the behaviour, would it be possible to document that the DBI example code doesn't work, and the reasoning for using a type value of -1? Thanks for your help, Mick (Sorry if you receive this twice, finding how to post here was tricky...) -- Mick Brooks Chief String Puller http://www.we7.com