Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-interfaces by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group