|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80892 PDO::PARAM_INT is treated the same as PDO::PARAM_STR
Submitted: 2021-03-21 14:10 UTC Modified: 2024-05-20 08:18 UTC
Avg. Score:4.0 ± 1.0
Reproduced:13 of 14 (92.9%)
Same Version:9 (69.2%)
Same OS:7 (53.8%)
From: benjamin dot morel at gmail dot com Assigned:
Status: Re-Opened Package: PDO PgSQL
PHP Version: 8.0.3 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
48 - 10 = ?
Subscribe to this entry?

 [2021-03-21 14:10 UTC] benjamin dot morel at gmail dot com
As reported on

The test script below fails because the pgsql driver seems to treat everything as PARAM_STR, despite being explicitly requested to bind the value as PARAM_INT; the "?" placeholder is therefore replaced with the string '4326' instead of the integer 4326.

The problem is, in PostGIS, the ST_Transform() function has different signatures with different behaviours depending on whether the second parameter is an integer or a string.

As far as I can see, because of this issue, there is no way to pass an actual integer to a function without using explicit, PostgreSQL-specific CAST syntax.

I believe this is a bug and the pgsql driver should respect PDO::PARAM_STR just like the mysql driver does.

Test script:
$pdo = new PDO('pgsql:host=localhost;port=5432', 'postgres', 'postgres');

$statement = $pdo->prepare("
    SELECT ST_AsText(
            ST_GeomFromText('POINT(0 0)', 2154),

$statement->bindValue(1, 4326, PDO::PARAM_INT);

Expected result:

Actual result:
PDOException: SQLSTATE[XX000]: Internal error: 7 ERROR: could not parse proj string '4326'


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-03-21 14:11 UTC] benjamin dot morel at gmail dot com
Sorry, typo. Should read:

> should respect PDO::PARAM_INT just like the mysql driver does.
 [2021-03-21 16:32 UTC]
-Assigned To: +Assigned To: mbeccati
 [2021-03-24 13:21 UTC]
The following pull request has been associated:

Patch Name: Fix bug #80892 PDO::PARAM_INT on pdo_pgsql
On GitHub:
 [2021-04-12 06:23 UTC]
Automatic comment on behalf of mbeccati
Log: Fix #80892: PDO::PARAM_INT is treated the same as PDO::PARAM_STR
 [2021-04-12 06:23 UTC]
-Status: Assigned +Status: Closed
 [2021-04-29 10:09 UTC]
-Status: Closed +Status: Re-Opened
 [2021-04-29 10:09 UTC]
Unfortunately the fix led to a fairly significant behaviour change. It has been decided to revert the change and leave the fix for later, possibly 8.1+ only.
 [2021-05-03 08:31 UTC] nredon at solune dot com
A regression occurs with smallint datatype with PostgreSQL.

PLSQL Function :

CREATE OR REPLACE FUNCTION public.check_int_param(param_int integer) RETURNS text AS
RETURN param_int::text; 
COST 100;

CREATE OR REPLACE FUNCTION public.check_smallint_param(param_smallint smallint) RETURNS text AS
RETURN param_smallint::text;
COST 100;

PHP Test script :

$pdo = new PDO('pgsql:host=;port=5432;dbname=test_php', 'postgres', 'postgres');

$val_test = 1234;

$statement = $pdo->prepare("SELECT check_int_param(:param1)"); //Integer datatype : OK
$statement->bindParam(':param1', $val_test, PDO::PARAM_INT);
$res = $statement->fetch(\PDO::FETCH_ASSOC);
// array(1) { ["check_int_param"]=> string(4) "1234" }

$statement = $pdo->prepare("SELECT check_smallint_param(:param1)"); //Smallint datatype was OK in PHP 7.3.3 but not anymore.
$statement->bindParam(':param1', $val_test, PDO::PARAM_INT); //No PDO::PARAM_SMALLINT available
$res = $statement->fetch(\PDO::FETCH_ASSOC);
//Fatal error: Uncaught PDOException: SQLSTATE[42883]: Undefined function: 7 ERROR: function check_smallint_param(integer) does not exist LINE 1: SELECT check_smallint_param($1) ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts.

Expected result:

// array(1) { ["check_int_param"]=> string(4) "1234" }

Workaround :
$statement = $pdo->prepare("SELECT check_smallint_param(:param1::smallint)");
 [2021-05-03 08:46 UTC]
Thanks nredon at solune dot com for the feedback. That indicates that fixing this bug would potentially be not viable for 8.1 too.
 [2021-05-18 01:40 UTC] vivo50lte at yahoo dot com
The following pull request has been associated:

Patch Name: Add commit ID to build info
On GitHub:
 [2024-05-20 08:18 UTC]
-Assigned To: mbeccati +Assigned To:
 [2024-05-20 08:18 UTC]
I don't think this one can be fixed without improvements in PDO to avoid massive regressions.

Removing assignment.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon May 20 23:01:31 2024 UTC