Support proto/enum as typename

[apstndb]

This PR adds NamedType.

it is required for PROTO/ENUM support:

• CAST AS ENUM
• CAST AS PROTO
• Use a protocol buffer message in a column definition

[makenowjust]

I'm concerned that it seems to be abusing Path for the field of NamedType. Path is a type for path expressions.

[apstndb]

OK. NamedType will have a raw []*Ident.

[apstndb]

FYI
In ZetaSQL, SELECT AS a.b.c is parsed as PathExpression node, so it is
https://github.com/google/zetasql/blob/194cd32b5d766d60e3ca442651d792c7fe54ea74/zetasql/parser/testdata/select_as_distinct_all.test#L239-L243

(Added) CAST(expr AS typename) is parsed as CastExpression(expr, SimpleType(PathExpression)...). There is no difference between native types and proto types.
https://github.com/google/zetasql/blob/194cd32b5d766d60e3ca442651d792c7fe54ea74/zetasql/parser/testdata/parser.test#L1194-L1264

[makenowjust]

It is abnormal that the struct with the suffix Expression is used as a type, so ZetaSQL's design is absolutely wrong.

[apstndb]

I think there is a confusion.

In GoogleSQL of Cloud Spanner(and ZetaSQL), path expression is a structure for dot-separated identifiers described in lexical structure document, and it is used in many places of ZetaSQL.
https://cloud.google.com/spanner/docs/reference/standard-sql/lexical#identifier_examples
https://cloud.google.com/spanner/docs/reference/standard-sql/lexical#path_expressions

path:
  [path_expression][. ...]

path_expression:
  [first_part]/subsequent_part[ { / | : | - } subsequent_part ][...]

(It seems they call path as "path expression" in many situation.)

Generally, expr.expr can be parsed as field access operator GoogleSQL expression.
https://cloud.google.com/spanner/docs/reference/standard-sql/operators#field_access_operator.

Question: Why do we care about a path expression being a GoogleSQL expression?

[makenowjust]

A: Use a field Path []*Ident for that purpose like in this PR and UpdateItem.

memefish/ast/ast.go

Line 2431 in 8af8b41

Path []*Ident // len(Path) > 0

[apstndb]

I think many nodes need dot-separated identifiers to implement named schemas.
Should all they have raw []*Ident?

[apstndb]

I think it is similar in that *ast.Ident is a ast.Expr but it is used in many places.

[makenowjust]

I'm sorry. I will explain the essential issue. Path is a list of dot-chained identifiers, where len(Idents) >= 2 is a constraint. However, your use of it this time clearly violated it. Then, you needed to fix it. I feel it's my fault for not explaining that this is the biggest problem, and the GoogleSQL/ZetaSQL situation is not important here.

In the future, if ASTs similarly appear frequently where len(Idents) > 0 (len(Path) > 0) is a constraint, then it is worth naming such a structure. Also, we could consider using Path (even if it is not an expression) if we see a dot-chained list in the syntax where len(Idents) >= 2.

[apstndb]

Thank you for explaining.
We will discuss this topic another time. (It would be in named schema #100).

I think there are no reason to have deeper hierarchy as NamedType{Path{[]*Ident}}, so I agree NamedType should have []*Ident simply.