On Sun, Oct 12, 2008 at 02:55:51AM -0000, Greg Sabino Mullane wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> > values are hashrefs of type information in the same form as that
> > provided to the various bind_param() methods
> ...
>
> > I'm not sure why the values of the keys are hash references unless
> > multiple values are to be stored. If multiple values per key are stored
> > what are they typically? I can only find one DBD which implements
> > ParamTypes (DBD::Pg) and unless I am mistaken it sets the values of the
> > keys to a scalar value - the type of the parameter.
>
> Yes, it's scalar values in DBD::Pg. If I recall correctly, it was done that
> way simply because it seemed better to return a simple name. To be 100%
> accurate it should probably return a hashref because that's what bind_param
> takes. In other words:
>
> $sth->bind_param('$1', 234, { pg_type => SQL_INTEGER });
> warn Dumper $sth->{ParamTypes};
>
> gives:
>
> $VAR1 = {
> '1' => 'integer'
> };
>
> When it should technically return:
>
> $VAR1 = {
> '1' => { pg_type => 'SQL_INTEGER' }
> };
The intention is that this code:
$ParamTypes = $sth1->{ParamTypes};
$ParamValues = $sth1->{ParamValues};
$sth2->bind_param( $_, $ParamValues->{$_}, $ParamTypes->{$_} )
for keys %$ParamTypes;
should make the values bound to $sth2, and the way they're treated by
the driver, be the same way as they were for $sth1.
So { '1' => 'integer' } sure looks like a bug.
> However, bind_param currently saves the value to an internal form, without
> saving how it got there, which makes the key of that inner hash ('pg_type')
> difficult to show. Because the value, SQL_INTEGER, is really a constant, it's
> equally difficult to know to output 'SQL_INTEGER' - we'd really have to output
> the number it maps to.
Yes. Outputting the _string_ "SQL_INTEGER" would be wrong as it wouldn't
work for the code above.
> I can easily adjust ParamTypes in DBD::Pg to give a hashref, if that's
> what you end up doing for DBD::ODBC
Tim.
