Edit Report a Bug

    pg_last_error

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

    pg_last_error — 得到某连接的最后一条错误信息

    说明

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

    pg_last_error() 返回指定 connection 的最后一条错误信息。

    错误信息可能会被调用的 PostgreSQL(libpq) 内部函数覆盖。如果 PostgreSQL 的内部模块函数产生了多个错误，则可能不能返回适当的错误信息。

    使用 pg_result_error()、pg_result_error_field()、pg_result_status() 和 pg_connection_status() 用于更好的错误处理。

    注意:

    本函数以前的名字为 pg_errormessage()。

    参数

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

    警告

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

    返回值

    string，包含指定 connection 的最后一条错误消息。

    更新日志

    版本 说明
    8.1.0 现在 connection 参数接受 PgSql\Connection 实例，之前接受 resource。
    8.0.0 connection 现在可为 null。

    示例

    示例 #1 pg_last_error() 示例

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

    // 查询失败
    $res = pg_query($dbconn, "select * from doesnotexist");

    echo     pg_last_error($dbconn);
    ?>

    参见

    add a note add a note

    User Contributed Notes 1 note

    up
    5
    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 add a note
    To Top