pg_last_error

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

pg_last_error — Get the last error message string of a connection

Description

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

pg_last_error() returns the last error message for a given connection.

Error messages may be overwritten by internal PostgreSQL (libpq) function calls. It may not return an appropriate error message if multiple errors occur inside a PostgreSQL module function.

Use pg_result_error(), pg_result_error_field(), pg_result_status() and pg_connection_status() for better error handling.

Note:
This function used to be called pg_errormessage().

Parameters

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().

Warning

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

Return Values

A string containing the last error message on the given connection.

Changelog

Version	Description
8.1.0	The `connection` parameter expects an PgSql\Connection instance now; previously, a resource was expected.
8.0.0	`connection` is now nullable.

Examples

Example #1 pg_last_error() example

<?php
  $dbconn = pg_connect("dbname=publisher") or die("Could not connect");

  // Query that fails
  $res = pg_query($dbconn, "select * from doesnotexist");
  
  echo pg_last_error($dbconn);
?>

User Contributed Notes 1 note

down

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

add a note