Tom,
Thanks for suggestion - I'm gonna try this patch:
--- dbdimp.c.bak Wed Apr 6 16:40:20 2005
+++ dbdimp.c Fri Apr 8 15:21:29 2005
@@ -1415,7 +1415,7 @@ } else if (NULL == currph->bind_type) { /* "sticky" data type */ /*
Thisis the default type, but we will honor
defaultval if we can */
- currph->bind_type = pg_type_data(VARCHAROID);
+ currph->bind_type = pg_type_data(UNKNOWNOID); if (!currph->bind_type)
croak("Default type is bad!!!!???"); }
On Apr 8, 2005 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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
>
--
Vlad
