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

Reply via email to