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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-php by date

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