Re: Planned cleanups in attribute parsing

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

Right.

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

Is there a one-to-one relationship between the alias and the column? Or
does the list of column names actually have more than one entry? Or is
the "list of column alias names" the qualified name of the column?

> 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).

Would it be helpful to separate the name itself from the qualifying
prefixes? istm that most use cases would require this anyway...

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

OK.

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

OK.

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

Nodes are better imho.

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

Hmm. I can't think of a case where either columns *or* tables could be
mentioned and where a table name would take precedence. otoh we should
decide pretty carefully that this will *never* happen before ripping too
much out.
                    - Thomas