Re: Planned cleanups in attribute parsing

Tom Lane wrote:
>
> 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.
>

These sound good to me.

> 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?
>

We can handle most cases with RangeVar (+ the ones you've proposed
above).
The schema name will have to go into RangeVar anyway.

> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9