-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> If the statement handle came from DBD::Sponge then why would DBD::Pg's
> fetch method be executed? When a row is fetched from a DBD::Sponge
> statement handle DBD::Pg won't be involved at all.
Thanks, I think I was following the wrong code path. Not that I understand
exactly what is happening yet, but I no longer suspect DBD::Sponge as
the problem. The issue is that code like this does not work:
$dbh->{pg_expand_array} = 0;
$sth = $dbh->foreign_key_info(undef,undef,$table1,undef,undef,$table2);
$sth->execute();
$result = $sth->fetchrow_hashref();
The foreign_key_info sub gets a dbh which it uses throughout its existence:
sub foreign_key_info {
my $dbh = shift;
This appears to be a different object from the "user-level" $dbh at the
first line of the example above. As such, I can set this inside of
foreign_key_info:
$dbh->{pg_expand_array} = 1;
However, inside of the fetch routine (dbdimp.c:dbd_st_fetch), the old
pg_expand_array value (0) is seen. I need a way to force pg_expand_array
to be 1 while it is fetching things from the internal methods such
as foreign_key_info. To be more precise, the imp_sth struct inside of
fetch needs to be set to expand_array=0 before it arrives, or have some
way to detect that it came from foreign_key_info so I can ignore the
user setting.
I suspect the problem lays in a disconnect between that first $dbh
object and the one that is passed in to foreign_key_info. How can
I derive the first from the second?
- --
Greg Sabino Mullane [email protected]
PGP Key: 0x14964AC8 201311091154
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlJ+aSIACgkQvJuQZxSWSsgavACfXMw2kJgrSPhWAGLFWT8sTNU4
lNkAmwWXagapl4yDFmBHz40n+8Xt5svJ
=Y3RD
-----END PGP SIGNATURE-----
