pg_last_error
(PHP 4 >= 4.2.0, PHP 5)
pg_last_error — Получает сообщение о последней произошедшей ошибке на соединении с базой данных
Описание
$connection
] )
pg_last_error() возвращает сообщение о последней ошибке
на заданном соединении connection
.
Сообщения об ошибках могут перезаписываться при внутренних вызовах PostgreSQL (libpq) функций. Если внутри модуля PostgreSQL произойдет несколько ошибок, сообщение может оказаться неинформативным.
Для обработки ошибок лучше использовать функции pg_result_error(), pg_result_error_field(), pg_result_status() и pg_connection_status().
Замечание:
Прежнее название функции: pg_errormessage().
Список параметров
-
connection
-
Ресурс подключения к базе данных PostgreSQL. Если параметр
connection
не задан, будет использовано подключение по умолчанию - последнее соединение, открытое функцией pg_connect() или pg_pconnect().
Возвращаемые значения
Строка, содержащая сообщение о последней ошибке, произошедшей на
соединении connection
, либо FALSE
в
случае ошибки.
Примеры
Пример #1 Пример использования pg_last_error()
<?php
$dbconn = pg_connect("dbname=publisher") or die("Невозможно соединиться с сервером");
// Неудачный запрос
$res = pg_query($dbconn, "select * from doesnotexist");
echo pg_last_error($dbconn);
?>
Смотрите также
- pg_result_error() - Возвращает сообщение об ошибке, связанной с запросом результата
- pg_result_error_field() - Возвращает конкретное поле из отчета об ошибках
- PHP Руководство
- Функции по категориям
- Индекс функций
- Справочник функций
- Расширения для работы с базами данных
- Расширения для работы с базами данных отдельных производителей
- PostgreSQL
- pg_affected_rows
- pg_cancel_query
- pg_client_encoding
- pg_close
- pg_connect_poll
- pg_connect
- pg_connection_busy
- pg_connection_reset
- pg_connection_status
- pg_consume_input
- pg_convert
- pg_copy_from
- pg_copy_to
- pg_dbname
- pg_delete
- pg_end_copy
- pg_escape_bytea
- pg_escape_identifier
- pg_escape_literal
- pg_escape_string
- pg_execute
- pg_fetch_all_columns
- pg_fetch_all
- pg_fetch_array
- pg_fetch_assoc
- pg_fetch_object
- pg_fetch_result
- pg_fetch_row
- pg_field_is_null
- pg_field_name
- pg_field_num
- pg_field_prtlen
- pg_field_size
- pg_field_table
- pg_field_type_oid
- pg_field_type
- pg_flush
- pg_free_result
- pg_get_notify
- pg_get_pid
- pg_get_result
- pg_host
- pg_insert
- pg_last_error
- pg_last_notice
- pg_last_oid
- pg_lo_close
- pg_lo_create
- pg_lo_export
- pg_lo_import
- pg_lo_open
- pg_lo_read_all
- pg_lo_read
- pg_lo_seek
- pg_lo_tell
- pg_lo_truncate
- pg_lo_unlink
- pg_lo_write
- pg_meta_data
- pg_num_fields
- pg_num_rows
- pg_options
- pg_parameter_status
- pg_pconnect
- pg_ping
- pg_port
- pg_prepare
- pg_put_line
- pg_query_params
- pg_query
- pg_result_error_field
- pg_result_error
- pg_result_seek
- pg_result_status
- pg_select
- pg_send_execute
- pg_send_prepare
- pg_send_query_params
- pg_send_query
- pg_set_client_encoding
- pg_set_error_verbosity
- pg_socket
- pg_trace
- pg_transaction_status
- pg_tty
- pg_unescape_bytea
- pg_untrace
- pg_update
- pg_version
Коментарии
From a practical view there are two types of error messages when using transactions:
-"Normal" errors: in this case, the application should stop the current process and show an error message to the user.
-Deadlock errors. This shows that the deadlock detection process of PostgreSQL found a circle of dependency, and broke it by rolling back the transaction in one of the processes, which gets this error msg. In this case, the application should not stop, but repeat the transaction.
I found no discrete way to find out which case are we dealing with. This interface doesn't support error codes, so we have to search for patterns in the message text.
Here is an example for PostgreSQL database connection class. It throws a PostgresException on "normal" errors, and DependencyException in the case of a broken deadlock, when we have to repeat the transaction.
postgres.php:
<?php
class PostgresException extends Exception {
function __construct($msg) { parent::__construct($msg); }
}
class DependencyException extends PostgresException {
function __construct() { parent::__construct("deadlock"); }
}
class pg {
public static $connection;
private static function connect() {
self::$connection = @pg_connect("dbname=foodb user=foouser password=foopasswd");
if (self::$connection === FALSE) {
throw(new PostgresException("Can't connect to database server."));
}
}
public static function query($sql) {
if (!isset(self::$connection)) {
self::connect();
}
$result = @pg_query(self::$connection, $sql);
if ($result === FALSE) {
$error = pg_last_error(self::$connection);
if (stripos($error, "deadlock detected") !== false) throw(new DependencyException());
throw(new PostgresException($error.": ".$sql));
}
$out = array();
while ( ($d = pg_fetch_assoc($result)) !== FALSE) {
$out[] = $d;
}
return $out;
}
}
?>
It should be used in this way:
test.php:
<?php
include("postgres.php");
do {
$repeat = false;
try {
pg::query("begin");
...
$result = pg::query("SELECT * FROM public.kitten");
...
pg::query("commit");
}
catch (DependencyException $e) {
pg::query("rollback");
$repeat = true;
}
} while ($repeat);
?>
The normal errors should be caught at the frontend.
Tamas