Is Wez of the PHP project correct here in that you can't find parameter
types of statements via libpq?
Chris
-------- Original Message --------
Subject: [PHP-CVS] cvs: php-src(PHP_5_1) /ext/pdo_pgsql package.xml
pgsql_driver.c pgsql_statement.c php_pdo_pgsql_int.h
Date: Fri, 25 Nov 2005 03:35:06 -0000
From: Wez Furlong <[EMAIL PROTECTED]>
To: php-cvs@lists.php.net
wez Thu Nov 24 22:35:06 2005 EDT
Modified files: (Branch: PHP_5_1)
/php-src/ext/pdo_pgsql package.xml pgsql_driver.c pgsql_statement.c
php_pdo_pgsql_int.h
Log:
Addresses #35338.
Postgres client API is pretty poor, so we have zero idea about the actual
parameter types in a statement.
We now defer the preparation of a statement until the first call to
execute is
made. At that point, we have the parameters defined by the calling
script, so
we can use the typing specified there when we perform the prepare.
For PDO_PARAM_LOB parameters, we set the binary formatting flag.
We can't just set this flag for all parameters, because its meaning
is not
"string data, counted length" but "data is in native format". If
this flag is
set for a numeric column and we send the number 1 formatted as a
string, then
we will get an "insufficient data left in message" error message,
because the
library was expecting sizeof(int4) bytes but only saw 1 byte for "1".
This is infuriating because we have no way to determine the datatypes for
parameters, and the type we explicitly set has to match the type in the
database. The only choice we're left with is telling postgres to
deduce the
type; we still have no idea what type was deduced.
<cvs diffs omitted>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
