CascadiaPHP 2024

pg_last_error

(PHP 4 >= 4.2.0, PHP 5, PHP 7, PHP 8)

pg_last_errorObtém a última string da mensagem de erro de uma conexão

Descrição

pg_last_error(?PgSql\Connection $connection = null): string

pg_last_error() retorna a última mensagem de erro para uma determinada connection.

As mensagens de erro podem ser substituídas por chamadas de função internas do PostgreSQL (libpq). Pode não retornar uma mensagem de erro apropriada se ocorrerem vários erros dentro de uma função do módulo PostgreSQL.

Use pg_result_error(), pg_result_error_field(), pg_result_status() e pg_connection_status() para melhor tratamento de erros.

Nota:

Esta função costumava ser chamada de pg_errormessage().

Parâmetros

connection

Uma instância de PgSql\Connection. Quando o parâmetro connection for null, a conexão padrão será usada. A conexão padrão é a última conexão feita por pg_connect() ou pg_pconnect().

Aviso

A partir do PHP 8.1.0, usar a conexão padrão tornou-se defasado.

Valor Retornado

Uma string contendo a última mensagem de erro na connection fornecida.

Registro de Alterações

Versão Descrição
8.1.0 O parâmetro connection agora espera uma instância de PgSql\Connection; anteriormente, um resource era esperado.
8.0.0 connection agora é anulável.

Exemplos

Exemplo #1 Exemplo de pg_last_error()

<?php
$dbconn
= pg_connect("dbname=publisher") or die("Não foi possível conectar");

// Consulta que falha
$res = pg_query($dbconn, "select * from doesnotexist");

echo
pg_last_error($dbconn);
?>

Veja Também

add a note

User Contributed Notes 1 note

up
4
Tamas Bolner
13 years ago
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
To Top