[DBAL-76] PostgreSQL Platform list* SQL code is in need of serious love Created: 12/Dec/10 Updated: 08/Jun/11 |
|
| Status: | Open |
| Project: | Doctrine DBAL |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The Postgres Schema code is very hard to read and inconsistent across the board. Some use pg_class, some pg_tables. Namespaces /Schema are not always properly checked for. There should be a really unified way on how to approach schema query issues. |
| Comments |
| Comment by Denis [ 08/Jun/11 ] |
|
I'm not sure what this ticket is about exactly, but... "Namespaces /Schema are not always properly checked for." Usually, one would not want to specify them and set the search_path instead. Or are you meaning the schema analysis queries used internally? (If so, yes, it kind of sucks in that case, but note that there are a bunch of *_is_visible() methods, e.g. pg_catalog.pg_table_is_visible(rel.oid) which will strip out invisible schemas directly. This may be simpler than injecting schema references all over the place in that it also processes permissions.) Also, note that PG has a whole bunch of pg_catalog views, which are available in the information_schema. |