To: Vlad <marchenko@gmail.com>
Cc: Brandon Metcalf <bmetcalf@nortel.com>,
	dbdpg-general@gborg.postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg 
In-reply-to: <cd70c68105040811403321e846@mail.gmail.com> 
References: <Pine.LNX.4.58L.0504081127400.18466@cash.rhiamet.com>
	<cd70c6810504081112694ba268@mail.gmail.com>
	<Pine.LNX.4.58L.0504081316270.18466@cash.rhiamet.com>
	<cd70c68105040811403321e846@mail.gmail.com>
Comments: In-reply-to Vlad <marchenko@gmail.com>
	message dated "Fri, 08 Apr 2005 14:40:04 -0400"
Date: Fri, 08 Apr 2005 15:11:49 -0400
Message-ID: <16221.1112987509@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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