Thread: [Fwd: [PHP-CVS] cvs: php-src(PHP_5_1) /ext/pdo_pgsql package.xml pgsql_driver.c pgsql_statement.c php_pdo_pgsql_int.h]

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 <wez@php.net>
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
hasto 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>


Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Is Wez of the PHP project correct here in that you can't find parameter 
> types of statements via libpq?

Per the description of PQprepare:

: At present, there is no way to determine the actual data type inferred
: for any parameters whose types are not specified in paramTypes[]. This
: is a libpq omission that will probably be rectified in a future release.

We need a function that exposes the protocol's Describe Statement
functionality ... or possibly better, extend PQprepare to include it.
(If PQprepare just does it automatically, then you don't need an extra
network round trip to get the info.)

I don't think this is as big a problem as he makes it out to be, though.
You should only be trying to use binary format for parameters that you
know darn well the type of, and for those you can make sure that you
specify the type to PQprepare instead of leaving it to be inferred.
Depending on the type-inference facility for arbitrary queries is
dangerous anyway.
        regards, tom lane