From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Planned cleanups in attribute parsing |
Date: | 2002-03-04 22:52:26 |
Message-ID: | 8737.1015282346@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2002-03-04 23:05:07 | Re: Uniqueness of rule, constraint, and trigger names |
Previous Message | Stephan Szabo | 2002-03-04 22:51:16 | Re: Uniqueness of rule, constraint, and trigger names |