Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vlad <marchenko(at)gmail(dot)com>
Cc: Brandon Metcalf <bmetcalf(at)nortel(dot)com>, dbdpg-general(at)gborg(dot)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg
Date: 2005-04-08 19:11:49
Message-ID: 16221.1112987509@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Vlad <marchenko(at)gmail(dot)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

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Vlad 2005-04-08 19:22:32 Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg
Previous Message Brandon Metcalf 2005-04-08 19:10:33 Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg