mirror of
https://github.com/postgres/postgres.git
synced 2026-02-23 18:04:41 -05:00
c4d3cd3dc8
The previous coding labeled expressions such as pg_index.indkey[1:3] as being of int2vector type; which is not right because the subscript bounds of such a result don't, in general, satisfy the restrictions of int2vector. To fix, implicitly promote the result of slicing int2vector to int2[], or oidvector to oid[]. This is similar to what we've done with domains over arrays, which is a good analogy because these types are very much like restricted domains of the corresponding regular-array types. A side-effect is that we now also forbid array-element updates on such columns, eg while "update pg_index set indkey[4] = 42" would have worked before if you were superuser (and corrupted your catalogs irretrievably, no doubt) it's now disallowed. This seems like a good thing since, again, some choices of subscripting would've led to results not satisfying the restrictions of int2vector. The case of an array-slice update was rejected before, though with a different error message than you get now. We could make these cases work in future if we added a cast from int2[] to int2vector (with a cast function checking the subscript restrictions) but it seems unlikely that there's any value in that. Per report from Ronan Dunklau. Back-patch to all supported branches because of the crash risks involved. |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| analyze.c | ||
| check_keywords.pl | ||
| gram.y | ||
| keywords.c | ||
| kwlookup.c | ||
| Makefile | ||
| parse_agg.c | ||
| parse_clause.c | ||
| parse_coerce.c | ||
| parse_collate.c | ||
| parse_cte.c | ||
| parse_expr.c | ||
| parse_func.c | ||
| parse_node.c | ||
| parse_oper.c | ||
| parse_param.c | ||
| parse_relation.c | ||
| parse_target.c | ||
| parse_type.c | ||
| parse_utilcmd.c | ||
| parser.c | ||
| README | ||
| scan.l | ||
| scansup.c | ||
src/backend/parser/README Parser ====== 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 kwlookup.c turn keywords into specific tokens keywords.c table of standard keywords (passed to kwlookup.c) gram.y parse the tokens and produce a "raw" parse tree analyze.c top level of parse analysis for optimizable queries parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ... parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ... parse_coerce.c handle coercing expressions to different data types parse_collate.c assign collation information in completed expressions parse_cte.c handle Common Table Expressions (WITH clauses) parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4 parse_func.c handle functions, table.column and column identifiers parse_node.c create nodes for various structures parse_oper.c handle operators in expressions parse_param.c handle Params (for the cases used in the core backend) parse_relation.c support routines for tables and column handling parse_target.c handle the result list of the query parse_type.c support routines for data type handling parse_utilcmd.c parse analysis for utility commands (done at execution time)