PHP 8.5.0 Alpha 1 available for testing

pg_last_error

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

pg_last_error Lee el último mensaje de error en la conexión

Descripción

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

pg_last_error() devuelve el último mensaje de error para una conexión connection.

Los mensajes de error pueden ser sobrescritos por llamadas internas a la extensión PostgreSQL (libpq): es posible que el mensaje devuelto no sea apropiado, especialmente si han ocurrido múltiples errores en el módulo.

Utilícese pg_result_error(), pg_result_error_field(), pg_result_status() y pg_connection_status() para mejorar la gestión de errores.

Nota:

Anteriormente, esta función se llamaba pg_errormessage().

Parámetros

connection

An PgSql\Connection instance. When connection is null, the default connection is used. The default connection is the last connection made by pg_connect() or pg_pconnect().

Advertencia

As of PHP 8.1.0, using the default connection is deprecated.

Valores devueltos

Un chaîne de caractères que contiene el último mensaje de error en la conexión connection.

Historial de cambios

Versión Descripción
8.1.0 The connection parameter expects an PgSql\Connection instance now; previously, a recurso was expected.
8.0.0 connection ahora es nullable.

Ejemplos

Ejemplo #1 Ejemplo con pg_last_error()

<?php
$dbconn
= pg_connect("dbname=publisher") or die("Conexión imposible");

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

echo
pg_last_error($dbconn);
?>

Ver también

add a note

User Contributed Notes 1 note

up
6
Tamas Bolner
14 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