Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg
Date
Msg-id 16221.1112987509@sss.pgh.pa.us
Whole thread Raw
In response to Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg  (Vlad <marchenko@gmail.com>)
Responses Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg
List pgsql-interfaces
Vlad <marchenko@gmail.com> writes:
> Ideallly a programmer doesn't need to care to specify column type when
> putting a code like this (assuming C is of an "int" type ):

> my $sth = $dbh->prepare_cached( "select A from B where C=?");
> $sth->execute( 123 );
> ...

> and DBD::Pg would guess (don't ask me how) the column types and pass
> it to postgresql so the query executed in most efficient way.

DBD::Pg shouldn't need to do any such thing --- the backend can do it a
whole lot better than DBD::Pg could.  What should be happening here is
that if DBD::Pg hasn't been told a specific type for the parameter, it
should pass the parameter type to the backend as "UNKNOWN" (yes, there
is such a type ID) and let the backend try to infer the type.

There are cases where there's not enough information to infer the type,
and then the programmer has to provide it, either by writing a cast in
the query text or by passing the info to bind_param.  It sounds like
bind_param could do with some work too ... but 80% of this issue would
go away if UNKNOWN were being used correctly.
        regards, tom lane


pgsql-interfaces by date:

Previous
From: Vlad
Date:
Subject: Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg
Next
From: Vlad
Date:
Subject: Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg