MySQL与PostgreSQL查询参数处理的标准方案及相关疑问

自定义参数处理函数 prmstr #

function prmstr($v){
    switch(gettype($v)){ 
        case 'integer':case 'double': return (string)$v;    
        case 'NULL': return 'NULL';     
        case 'boolean':return $v?'true':'false';
        default: $v=pg_escape_string($v);return "'{$v}'";// may be redundant to use pg_escape_string
    }
}

使用示例 #

单个参数处理

$p1=456; $p2='A9XXP';
$qs="select * from tb where c1=$1 and c2=$2";
$qr=pg_query_params('select * from tb where c1=$1 and c2=$2',[prmstr($p1),prmstr($p2)]);

批量参数处理

// 假设已定义prmstrA函数实现批量处理
$qr=pg_query_params('select * from tb where c1=$1 and c2=$2',prmstrA([$p1,$p2]));

核心问题解答 #

1. 标准实现方式 #

你当前用的pg_query_params本身就是PostgreSQL官方推荐的参数化查询标准方案，完全不需要手动写prmstr这类转换函数。参数化查询会自动完成参数的类型适配、安全转义，根本不用你手动拼接字符串或者处理类型转换。

对应MySQL的标准实现是：

• 使用mysqli_prepare配合mysqli_stmt_bind_param
• 或者用PDO的参数化查询（PDO::prepare + PDOStatement::execute）

这些都是官方支持的安全、标准的参数处理方式，完全覆盖你自定义函数的需求，且更可靠。

2. pg_escape_string的问题与注意事项 #

• 完全冗余且易出错：pg_query_params会自动安全处理参数，你手动用pg_escape_string再加引号，会导致参数被双重处理。比如原参数是O'Neil，转义后变成O''Neil，再加引号成'O''Neil'，传到参数化查询里会被当成带引号的字符串字面量，而非原本的参数值，直接导致查询逻辑错误。
• 字符编码风险：pg_escape_string依赖当前数据库连接的字符编码设置，编码不匹配时会出现转义错误，可能引发SQL注入或乱码。参数化查询则完全不受编码设置影响，驱动会自动适配。
• 类型不兼容：你把PHP布尔值转成'true'/'false'字符串，但PostgreSQL的布尔类型接受的是不带引号的TRUE/FALSE或1/0，传带引号的字符串会触发类型不匹配报错。参数化查询会自动把PHP布尔值转换成PostgreSQL可识别的布尔类型，无需手动转换。

总结：自定义prmstr完全没必要，反而容易引入bug和安全风险，直接使用官方提供的参数化查询API即可。

内容的提问来源于stack exchange，提问作者George Kourtis