php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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: Thu Apr 25 19:01:33 2024 UTC