Re: Getting statement handle attributes from dbdimp.c

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.