PGAdmin 成功但 PDO 查询失败

Question

I am wanting to get column information on a Postgres database table. I am using the following query:

select column_name as "Field", data_type as "Type", is_nullable as "Null", character_maximum_length as "max_length" from information_schema.columns where table_name='testempty'

(At some point, I will be removing the AS clauses. I had reasons for including them when I originally set up this query, but these reasons have since evaporated.)

When I run the query in PGAdmin, I get the results I expect: There are 2 columns, and I see their requested details. When I execute the same query using PDO in PHP, I get 0 rows back. No errors, the execute call returns true. Here is the PHP code:

try {
    $remote_statement = $remote_con->prepare($column_query);
    $remote_exec = $remote_statement->execute();
} catch(Exception $e) {
    file_put_contents("logs/remote.log", '[' . date("Y-m-d H:i:s") . ' ' . $_SERVER["REMOTE_ADDR"] . "] Prepare failed: " . $e->getMessage() . "\n", FILE_APPEND);
}
if (!$remote_exec) {
    file_put_contents("logs/remote.log", '[' . date("Y-m-d H:i:s") . ' ' . $_SERVER["REMOTE_ADDR"] . "] Execute failed\n", FILE_APPEND);
}
$remote_error = $remote_statement->errorInfo();
if (!empty($remote_error[2])) {
    file_put_contents("logs/remote.log", '[' . date("Y-m-d H:i:s") . ' ' . $_SERVER["REMOTE_ADDR"] . "] Query failed: " . $remote_error[2] . "\n", FILE_APPEND);
    die($remote_error);
}
$remote_rows = $remote_statement->fetchAll(PDO::FETCH_ASSOC);

$remote_con is a PDO connection object I created earlier in the code. $column_query is set to the query I listed above. There is another table I run this same code on prior to this and I get the expected results.

I appreciate any helpful hints here. I am sure I am missing something obvious, but it baffles me that the query works in PGAdmin and not via a PHP call.

Answer 1

This turned out to be a table-specific permissions issue. Granted SELECT permissions to PUBLIC for a problem table and the query via PHP worked. I found another pair of tables in a different database with this issue, and all was resolved by granting this permission.