On Mon, Oct 13, 2008 at 11:53:34AM -0000, Greg Sabino Mullane wrote:
>
> > 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.
>
> Thanks for the clarification Tim, that all makes sense. I've changed DBD::Pg
> to
> do the right thing for ParamTypes. Specifically, it outputs a hash with
> placeholder
> numbers or names as keys, as before, and with a hashref for the values that
> contains a single key (always "pg_type") and the internal type number as the
> value.
>
> { 1 => { pg_type => 23 }, 2 => { pg_type => 1024 } }
>
> and
>
> { ':foo' => { pg_type => 23 }, ':foo2' => { pg_type => 1024 } }
Umm, looking at that it strikes me that if someone calls
bind_param( 1, $value, SQL_INTEGER ); # or { TYPE=>SQL_INTEGER }
and the drivers translates that into *just* it's oen private type
then valuable information has been lost.
Generic code wouldn't know how to interpret pg_type values.
Ideally the ParamTypes value should be a compatible superset of the
bind_param attributes, with not information lost.
Tim.
