On Sat, Nov 09, 2013 at 04:56:49PM -0000, Greg Sabino Mullane wrote:
>
> > 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.
Yes. The "user-level" $dbh is a reference to a tied hash. A tied hash
has two parts: an 'inner' hash that acts normally and and 'outer' hash
that triggers method calls like STORE and FETCH when accessed.
Driver methods are called on the inner hash/handle.
The $dbh->{pg_expand_array} above would have triggered a STORE method
call on the inner hash/handle.
> As such, I can set this inside of foreign_key_info:
>
> $dbh->{pg_expand_array} = 1;
That alters the inner hash directly, without calling STORE.
> However, inside of the fetch routine (dbdimp.c:dbd_st_fetch), the old
> pg_expand_array value (0) is seen.
I'd guess that pg_expand_array requires STORE to be called (e.g., it's
not implemented as a simple hash element).
> 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.
You probably want $dbh->STORE('pg_expand_array', 1); in 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.
Try the above.
> 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?
Let me know if the above isn't clear.
Tim.
