php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76916 pg_meta_data Does Not Respect PostgreSQL search_path
Submitted: 2018-09-21 15:44 UTC Modified: 2018-09-21 16:12 UTC
Votes:2
Avg. Score:2.0 ± 1.0
Reproduced:0 of 0 (0.0%)
From: klaxian at gmail dot com Assigned:
Status: Open Package: PostgreSQL related
PHP Version: 7.1.22 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: klaxian at gmail dot com
New email:
PHP Version: OS:

 

 [2018-09-21 15:44 UTC] klaxian at gmail dot com
Description:
------------
When querying for data about a PostgreSQL table, pg_meta_data() does not respect PostgreSQL's search_path setting. When the specified table is not explicitly qualified with a schema, the public schema is always assumed. This is hard-coded in the pgsql extension.

https://github.com/php/php-src/blob/master/ext/pgsql/pgsql.c#L5530

Test script:
---------------
pg_meta_data($link, 'test'); // always looks for "public.test"


Expected result:
----------------
When a table name is not explicitly qualified with a schema name, the server search_path setting should be used to determine the correct table.

Actual result:
--------------
When a table name is not explicitly qualified with a schema name, the public schema is always assumed.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-09-21 16:12 UTC] klaxian at gmail dot com
Currently, the function appears to parse the supplied table name for an explicit schema qualifier; "public" is assumed if one is not found. A query is constructed where c.relname and n.nspname match the supplied/assumed table and schema respectively. As I mentioned, this ignores PostgreSQL's search_path.

I suggest querying for the user-supplied table name casted to a PG regclass object instead. This improves performance because the table string won't need to be parsed and PostgreSQL will determine the correct object based on its search_path. This is supported in at least PG 7.3+ from 2002 (and likely older).

WHERE a.attrelid='mytable'::regclass
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 08:01:30 2024 UTC