Planned cleanups in attribute parsing
От | Tom Lane |
---|---|
Тема | Planned cleanups in attribute parsing |
Дата | |
Msg-id | 8737.1015282346@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
On the way to supporting schemas, I am thinking about trying to make the parsing of attributes a little more intelligible. The Attr node type seems overused to mean several different things. I'd like to do the following: For column references: Split "Attr" into three node types for different uses: Alias: for AS clauses. Carries a "char *aliasname" and a List of column alias names. The current uses of Attr in range table entries would become Alias. ColumnRef: for referencing a column (possibly qualified, possibly with array subscripts) in the raw grammar output. Carries a List of names which correspond to the dotted names (eg, a.b.c), plus a List of array subscripting info (currently called "indirection" in Attr, but I wonder if "subscripts" wouldn't be a more useful name). ParamRef: for referencing a parameter. Carries parameter number, possibly-empty list of field names to qualify the param, and a subscript list. The ParamNo node type goes away, to be merged into this. The Ident node type is not semantically distinct from ColumnRef with a one-element name list. Probably should retire it. Perhaps indirection should be split out as a separate node type, with an eye to allowing (arbitrary-expression)[42] someday. For table references: Currently, the table name associated with an unparsed statement is typically just a string. I propose replacing this with a RelationRef node type, carrying a List of names corresponding to the dotted names of the reference (1 to 3 names). Alternatively, we could just use the raw List of names and not bother with an explicit node; any preferences? Also, I think we could retire the notion of "relation vs. column precedence" in the parser. AFAICS the only place where transformExpr is told EXPR_RELATION_FIRST is for processing an Attr's paramNo --- but the ParamNo path through transformExpr never looks at the precedence! Accordingly, only the EXPR_COLUMN_FIRST cases are ever actually used anywhere, and there's no need for the notational cruft of passing precedence around. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: