mirror of
https://github.com/postgres/postgres.git
synced 2025-11-25 12:03:53 +03:00
862861ee77
namespace isn't necessarily first in the search path (there could be implicit schemas ahead of it). Examples are test=# set search_path TO s1; test=# create view pg_timezone_names as select * from pg_timezone_names(); ERROR: "pg_timezone_names" is already a view test=# create table pg_class (f1 int primary key); ERROR: permission denied: "pg_class" is a system catalog You'd expect these commands to create the requested objects in s1, since names beginning with pg_ aren't supposed to be reserved anymore. What is happening is that we create the requested base table and then execute additional commands (here, CREATE RULE or CREATE INDEX), and that code is passed the same RangeVar that was in the original command. Since that RangeVar has schemaname = NULL, the secondary commands think they should do a path search, and that means they find system catalogs that are implicitly in front of s1 in the search path. This is perilously close to being a security hole: if the secondary command failed to apply a permission check then it'd be possible for unprivileged users to make schema modifications to system catalogs. But as far as I can find, there is no code path in which a check doesn't occur. Which makes it just a weird corner-case bug for people who are silly enough to want to name their tables the same as a system catalog. The relevant code has changed quite a bit since 8.2, which means this patch wouldn't work as-is in the back branches. Since it's a corner case no one has reported from the field, I'm not going to bother trying to back-patch.
This directory does more than tokenize and parse SQL queries. It also creates Query structures for the various complex queries that are passed to the optimizer and then executor. parser.c things start here scan.l break query into tokens scansup.c handle escapes in input strings keywords.c turn keywords into specific tokens gram.y parse the tokens and fill query-type-specific structures analyze.c top level of parse analysis for optimizable queries parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ... parse_coerce.c handle coercing expressions to different types parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4 parse_oper.c handle operators in expressions parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ... parse_func.c handle functions, table.column and column identifiers parse_node.c create nodes for various structures parse_target.c handle the result list of the query parse_relation.c support routines for tables and column handling parse_type.c support routines for type handling parse_utilcmd.c parse analysis for utility commands (done at execution time)