Re: Planned cleanups in attribute parsing - Mailing list pgsql-hackers

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@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9