Re: PostgreSQL 7.4.x/CDBI bug

[prev] [thread] [next] [Date index for 2005/02/27]

Hi

> It doesn't sound like a Class::DBI problem to me, and is more likely
> in the lower level drivers (DBD::Pg or DBI).  Have you upgraded or
> re-installed those components?

That's quite right, but since DBD::Pg passes tests with flying colors,
I guess the problem might be higher up the hierarchy. It could be
DBIx::ContextualFetch, Ima::DBI or Class::DBI. I guess that also means
that the CDBI code is correct, isn't it?
> 
> Can you figure out what module is actually throwing the error (include
> the exact error message in your reply next time).  Is it Postgres that
> is throwing the error?

It's  DBD::Pg, but the code that gets passed to DBD::Pg is generated
by Class::DBI via Ima::DBI and DBIx::ContextualFetch. Once again, I'm
not sure where's exactly the problem.

> As a last resort, turn on DBI  tracing, or turn on tracing in postgres
> to see what exactly is happening in the database (ie what SQL
> statements are being executed, and what values are being passed.

What's happening is that, since Pgsql 7.4, binding must be done
explicitly. All values are bound as varchar, and some casting must be
done to other types, such as integer. That's why I use data_type. But,
somehow, it seems not to work, and I'm putting my money on DBD::Pg;
however, since it's XS code, it's far outside my turf.

> I usually add the following simple methods to my Class::DBI base
> class, which allows me to turn DBI tracing on and off directly in my
> code:
> 
> sub trace_on {
>   my $self  = shift;
>   my $level = shift || 1;
>   my $file = shift || '/tmp/dbi.trace';
>   $self->db_Main->trace($level, $file);
> }
> sub trace_off {
>   my $self = shift;
>   $self->db_Main->trace(0);
> }
> 
> Foo->trace_on;
> 
> Cheers,

Thanks, will do. If you think about anything else, please let me know.

JJ