Re: Help sought with definition and implementation of ParamTypes attribute

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.