Re: Stored procedures, PDO, and PHP issue - Mailing list pgsql-php

From Eric Chamberlain
Subject Re: Stored procedures, PDO, and PHP issue
Date
Msg-id B6A537B5-C287-44CD-A8A2-265086D3DB4F@zonarsystems.com
Whole thread Raw
In response to Re: Stored procedures, PDO, and PHP issue  (Andy Shellam <andy-lists@networkmail.eu>)
Responses Re: Stored procedures, PDO, and PHP issue  (Andy Shellam <andy-lists@networkmail.eu>)
List pgsql-php
On a hunch I have solved the problem.  You can not use the question mark syntax and the cast.  Instead you have to use the named parameters with the cast.

$stmt->prepare("SELECT is_password_expired(:user_id::INTEGER, :pass::VARCHAR);
$stmt->bindValue(':user_id', $userId);
$stmt->bindValue(':pass', $hashPass);
$stmt->execute();

Thank you all for your help!  You guys are awesome!

For completeness I'd like to answer your questions:

My cohort grabbed this information somewhere from the PHP site:

These are the conversions PDO does during binding. 
 
    * PDO::PARAM_STR converts whatever you give it to a string 
    * PDO::PARAM_INT converts bools into longs 
    * PDO::PARAM_BOOL converts longs into bools 
 
That's it. Nothing else is converted. PDO uses the PARAM flags to format SQL not to cast data types.

This explains why it didn't correctly identify the correct proc to use.

Hi Eric,


Unfortunately this does not work or I maybe doing it wrong.  New code:
$stmt = $db->prepare("SELECT is_password_expired($1::integer,
$2::varchar);
$stmt->bindValue(1, settype($userId, "integer"), PDO::PARAM_INT);
$stmt->bindValue(2, $hashPass, PDO::PARAM_STR);
$stmt->execute();

settype() doesn't return anything so it needs to be used on it's own
line.  E.g.:

That's very good to know!  It still didn't work, but at least I learned something new :)

$userId = "2"; // string
settype($userId, 'integer'); // $userId is now an integer
$stmt->bindValue(1, $userId, PDO::PARAM_INT);


I get a blank screen.  I've tried setting the error reporting level to:

error_reporting(E_ALL);

before calling the above code.  Our servers are configured to display
errors, etc.  The fact that it just goes blank tells me there is a
bigger issue going on.

Does your server definitely have display_errors set to On as well as the
error_reporting line, and it's not been overridden by your application?  
I've only ever known really serious errors (i.e. core dumps) to not
display anything even when display_errors is set to on.  What's logged
in your Apache or IIS error log?

It does have errors displayed.

Here is what is in the Apache log:

[Wed Aug 19 15:07:02 2009] [notice] child pid 31897 exit signal Segmentation fault (11)
[Wed Aug 19 15:07:03 2009] [notice] child pid 4163 exit signal Segmentation fault (11)
[Wed Aug 19 15:07:05 2009] [notice] child pid 4122 exit signal Segmentation fault (11)
[Wed Aug 19 15:07:07 2009] [notice] child pid 4209 exit signal Segmentation fault (11)

This was after 5 successive hits using the ?::BIGINT, ?::VARCHAR syntax.


Lastly have you tried "named" parameters?  From the PHP manual:  
(actually the PostgreSQL syntax "$1::integer" I suggested may have
caused PHP to crash as PDO uses a colon to introduce a named parameter.)

|$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':value', $value);|

Tried this.  No go.

pgsql-php by date:

Previous
From: Andy Shellam
Date:
Subject: Re: Stored procedures, PDO, and PHP issue
Next
From: Andy Shellam
Date:
Subject: Re: Stored procedures, PDO, and PHP issue