|  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
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
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
39 - 17 = ?
Subscribe to this entry?

 [2018-09-21 15:44 UTC] klaxian at gmail dot com
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.

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.


Add a Patch

Pull Requests

Add a Pull Request


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 Apr 21 00:01:28 2024 UTC