Skip site navigation (1) Skip section navigation (2)

Re: Stored procedures, PDO, and PHP issue

From: Eric Chamberlain <Eric(dot)Chamberlain(at)zonarsystems(dot)com>
To: Andy Shellam <andy-lists(at)networkmail(dot)eu>
Cc: "pgsql-php(at)postgresql(dot)org" <pgsql-php(at)postgresql(dot)org>
Subject: Re: Stored procedures, PDO, and PHP issue
Date: 2009-08-19 22:25:25
Message-ID: B6A537B5-C287-44CD-A8A2-265086D3DB4F@zonarsystems.com (view raw or flat)
Thread:
Lists: 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.

In response to

Responses

pgsql-php by date

Next:From: Andy ShellamDate: 2009-08-19 22:36:39
Subject: Re: Stored procedures, PDO, and PHP issue
Previous:From: Andy ShellamDate: 2009-08-19 21:15:41
Subject: Re: Stored procedures, PDO, and PHP issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group