pg_query_params
Посылает параметризованный запрос на сервер и ждёт результат. Параметры передаются отдельно от строки запроса.
pg_query_params() подобна функции pg_query() , но предоставляет дополнительный функционал: параметры запроса можно передавать отдельно от строки запроса. pg_query_params() поддерживается на соединениях с серверами PostgreSQL версий 7.4 и выше. Функция не будет работать с серверами ранних версий.
Если используются параметры params , они заменяют псевдопеременные $1, $2 и т.д. в строке запроса query . Один и тот же параметр может быть указан больше одного раза в query ; в этом случае будут использованы одинаковые значения. params определяют текущие значения параметров. Значение null в массиве параметров будет означать SQL NULL в запросе.
Главное преимущество pg_query_params() перед pg_query() заключается в том, что значения параметров могут передаваться отдельно от строки запроса query . Это даёт возможность избежать утомительную и подверженную ошибкам процедуру экранирования спецсимволов и заключения значений в кавычки. Однако, в отличие от pg_query() , эта функция поддерживает только один SQL запрос в передаваемой строке. (Он может содержать точку с запятой, но не более одной непустой SQL-команды.)
Список параметров
Экземпляр PgSql\Connection . Если connection не указано, используется соединение по умолчанию. Соединение по умолчанию — это последнее соединение, выполненное с помощью функций pg_connect() или pg_pconnect() .
Начиная с версии PHP 8.1.0, использование соединения по умолчанию устарело.
Параметризованный SQL запрос. Должен содержать только одно выражение (несколько выражений разделённых точкой с запятой не поддерживаются). Если в запрос будут передаваться параметры, то они заменят псевдопеременные $1, $2 и т.д.
Пользовательские данные всегда должны передаваться как параметры, и не передаваться в строку запроса напрямую, где они могут привести к возможным атакам через SQL-инъекции и приводит к ошибкам, если данные содержат кавычки. Если по каким-то причинам вы не можете использовать параметр, убедитесь, что пользовательские данные правильно экранированы.
Массив значений параметров запроса для замены псевдопеременных $1, $2 и т.д. в исходной строке запроса. Количество элементов массива должно точно совпадать с количеством псевдопеременных.
Значения предназначенные для bytea полей нельзя передавать в параметрах. Используйте функцию pg_escape_bytea() или функции для больших объектов.
Возвращаемые значения
Экземпляр PgSql\Result в случае успешного выполнения или false в случае возникновения ошибки.
Список изменений
| Версия | Описание |
|---|---|
| 8.1.0 | Возвращает экземпляр PgSql\Result ; ранее возвращался ресурс (resource). |
| 8.1.0 | Параметр connection теперь ожидает экземпляр PgSql\Connection ; ранее ожидался ресурс (resource). |
Примеры
Пример #1 Пример использования pg_query_params()
// Подключение к базе данных «mary»
$dbconn = pg_connect ( «dbname=mary» );
// Найдём все магазины с названием «Joe’s Widgets». Стоит отметить, что нет необходимости экранировать
// спецсимволы в строке «Joe’s Widgets»
$result = pg_query_params ( $dbconn , ‘SELECT * FROM shops WHERE name = $1’ , array( «Joe’s Widgets» ));
// Для сравнения то же самое, используя функцию pg_query
$str = pg_escape_string ( «Joe’s Widgets» );
$result = pg_query ( $dbconn , «SELECT * FROM shops WHERE name = ‘ < $str >‘» );
Смотрите также
User Contributed Notes 15 notes
Debugging parameterised queries can be tedious, if you want to paste the query directly into PSQL. Here is a trick that helps:
$sql = «SELECT * from table WHERE col_a = $1 and col_b=$2 and col_c=$3» ;
$params = array ( 42 , «a string» , NULL );
$debug = preg_replace_callback (
‘/\$(\d+)\b/’ ,
function( $match ) use ( $params ) <
$key =( $match [ 1 ]- 1 ); return ( is_null ( $params [ $key ])? ‘NULL’ : pg_escape_literal ( $params [ $key ]) );
>,
$sql );
echo » $debug » ;
//prints: SELECT * from table WHERE col_a = ’42’ and col_b=’a string’ and col_c=NULL
?>
This works correctly, except in the (unusual) case where we have a literal $N; the regexp replaces it where it shouldn’t. For example:
//Both ‘ . $1 . ‘ and $1 get replaced; the former is wrong, the latter is right.
$sql = «SELECT ‘Your bill is for $1’ AS invoice WHERE 7 = $1» ;
$params = array( 7 );
//$debug: SELECT ‘Your bill is for $7’ AS invoice WHERE 7 = ‘7’»
?>
You can’t run multiple statements with pg_query_params, but you can still have transaction support without falling back to pg_query:
$connection = pg_connect ( «host=127.0.0.1 port=5432 dbname=foo user=bar password=baz» );
pg_query ( $connection , ‘DROP TABLE IF EXISTS example’ );
pg_query ( $connection , ‘CREATE TABLE example (col char(1))’ );
pg_query ( $connection , ‘INSERT INTO example (col) VALUES (\’a\’)’ );
// ‘SELECT col FROM example’ in another session returns «a»
pg_query ( $connection , ‘BEGIN’ );
pg_query_params ( $connection , ‘UPDATE example SET col = $1’ , array( ‘b’ ));
// ‘SELECT col FROM example’ in another session still returns «a»
pg_query_params ( $connection , ‘UPDATE example SET col = $1’ , array( ‘c’ ));
// ‘SELECT col FROM example’ in another session still returns «a»
pg_query ( $connection , ‘COMMIT’ );
// ‘SELECT col FROM example’ in another session returns «c»
?>
pg_query and pg_query_params can be combined into a single function. This also removes the need to construct a parameter array for pg_query_params:
function my_query ( $conn , $query )
<
if( func_num_args () == 2 )
return pg_query ( $conn , $query );
$args = func_get_args ();
$params = array_splice ( $args , 2 );
return pg_query_params ( $conn , $query , $params );
>
?>
Usage:
/* non-parameterized example */
my_query ( $conn , «SELECT $val1 + $val2 » );
/* parameterized example */
my_query ( $conn , «SELECT $1 + $2» , $val1 , $val2 );
?>
If you need to provide multiple possible values for a field in a select query, then the following will help.
// Assume that $values[] is an array containing the values you are interested in.
$values = array( 1 , 4 , 5 , 8 );
// To select a variable number of arguments using pg_query() you can use:
$valuelist = implode ( ‘, ‘ , $values );
$query = «SELECT * FROM table1 WHERE col1 IN ( $valuelist )» ;
$result = pg_query ( $query )
or die( pg_last_error ());
// You may therefore assume that the following will work.
$query = ‘SELECT * FROM table1 WHERE col1 IN ($1)’ ;
$result = pg_query_params ( $query , array( $valuelist ))
or die( pg_last_error ());
// Produces error message: ‘ERROR: invalid input syntax for integer’
// It only works when a SINGLE value specified.
// Instead you must use the following approach:
$valuelist = »
$query = ‘SELECT * FROM table1 WHERE col1 = ANY ($1)’ ;
$result = pg_query_params ( $query , array( $valuelist ));
?>
The error produced in this example is generated by PostGreSQL.
The last method works by creating a SQL array containing the desired values. ‘IN (. )’ and ‘ = ANY (. )’ are equivalent, but ANY is for working with arrays, and IN is for working with simple lists.
Regarding boolean values, just typecast them as (integer) when passing them in your query — ‘0’ and ‘1’ are perfectly acceptable literals for SQL boolean input:
It is also safe to write your paramerized query in double-quotes, which allows you to mix constant values and placeholders in your query without having to worry about how whether PHP will attempt to substitute any variables in your parameterized string.
Of course this also means that unlike PHP’s double-quoted string syntax, you CAN include literal $1, $2, etc. inside SQL strings, e.g:
// Works ($1 is a placeholder, $2 is meant literally)
pg_query_params ( «INSERT INTO foo (col1, col2) VALUES ($1, ‘costs $2’)» , Array( $data1 ));
// Throws an E_WARNING (passing too many parameters)
pg_query_params ( «INSERT INTO foo (col1, col2) VALUES ($1, ‘costs $2’)» , Array( $data1 , $data2 ));
?>
A note on type-juggling of booleans:
pg_query_params() and friends do seamless, automatic conversion between PHP-NULL and SQL-NULL and back again, where appropriate.
Hoever, everything else goes in (and comes out) as a string.
The following approach may be helpful when handling boolean fields:
$sql = » . » ;
$params = array ( 1 , 2 , 3 , true , false );
//Now do the query:
$result = pg_query_params ( $sql , $params );
$row = pg_fetch_assoc ( $result , 0 ) //first row
//For booleans, convert ‘t’ and ‘f’ back to true and false. Check the column type so we don’t accidentally convert the wrong thing.
foreach ( $row as $key => & $value ) <
$type = pg_field_type ( $result , pg_field_num ( $result , $key ));
if ( $type == ‘bool’ ) $value = ( $value == ‘t’ );
>
>
//$row[] now contains booleans, NULLS, and strings.
?>
Third parameter $params of pg_query_params() ignores nay part of the string values after a zero byte character — PHP «\0» or chr(0). That may be a result of serialize().
Note that due to your locale’s number formatting settings, you may not be able to pass a numeric value in as a parameter and have it arrive in PostgreSQL still a number.
If your system locale uses «,» as a decimal separator, the following will result in a database error:
pg_query_params($conn, ‘SELECT $1::numeric’, array(3.5));
For this to work, it’s necessary to manually convert 3.5 to a string using e.g. number_format.
(I filed this as bug #46408, but apparently it’s expected behavior.)
When inserting into a pg column of type bool, you cannot supply a PHP type of bool. You must instead use a string «t» or «f». PHP attempts to change boolean values supplied as parameters to strings, and then attempts to use a blank string for false.
Example of Failure:
pg_query_params(‘insert into table1 (bool_column) values ($1)’, array(false));
Works:
pg_query_params(‘insert into lookup_permissions (system) values ($1)’, array(false ? ‘t’ : ‘f’));
If one of the parameters is an array, (eg. array of ints being passed to a stored procedure), it must be denoted as a set within the array, not php array notation.
eg: var_dump output of 2 parms an integer and array of int
aaa is: Array
(
[0] => 1
[1] =>
)