Enhance object name path segments #1539
Conversation
| @@ -4294,7 +4312,9 @@ impl<'a> Parser<'a> { | |||
| let mut data_type = self.parse_data_type()?; | |||
| if let DataType::Custom(n, _) = &data_type { | |||
| // the first token is actually a name | |||
| name = Some(n.0[0].clone()); | |||
| match n.0[0].clone() { | |||
| ObjectNamePart::Identifier(ident) => name = Some(ident), | |||
There was a problem hiding this comment.
Once we start adding more to the ObjectNamePart enum, we will return parsing error for the other variants here.
src/parser/mod.rs
Outdated
| @@ -10778,7 +10798,7 @@ impl<'a> Parser<'a> { | |||
| self.expect_token(&Token::LParen)?; | |||
| let aggregate_functions = self.parse_comma_separated(Self::parse_aliased_function_call)?; | |||
| self.expect_keyword(Keyword::FOR)?; | |||
| let value_column = self.parse_object_name(false)?.0; | |||
| let value_column = self.parse_period_separated_identifiers()?; | |||
There was a problem hiding this comment.
Giving this is a column name, we should parse it as period-separated identifiers and not as Object name.
|
I think |
ayman-sigma
force-pushed
the
ayman/improveObjectNameParts
branch
from
4b4998e to
18ca48f
Compare
There was a problem hiding this comment.
Thanks @ayman-sigma! left some minor comments, this looks good to me overall
ayman-sigma
force-pushed
the
ayman/improveObjectNameParts
branch
from
e22e3d8 to
176cf13
Compare
|
Hi @ayman-sigma this PR appears to have some conflicts. Is there any chance you can resolve them so we can merge it in? Thank you! |
ayman-sigma
force-pushed
the
ayman/improveObjectNameParts
branch
from
29f2610 to
6f05bcf
Compare
ayman-sigma
force-pushed
the
ayman/improveObjectNameParts
branch
from
6f05bcf to
7791973
Compare
@alamb, Done. |
There was a problem hiding this comment.
I started trying to update DataFusion to use this change -- it turns out to be fairly invasive.
You can try here: apache/datafusion#13546
(the issue is that we have a bunch of handling of ObjectName --> Indents code).
I think we can make the DataFusion code better / easier to follow
|
Given the potential for non trivial downstream conflicts due to this change (look at the list of conflicts it has already collected) I would like to consider it for the next release |
Sounds good. Thanks @alamb! |
Right now
ObjectNameis just list of identifiers. We parse each object name path segment as a string identifier. Some dialects has more rich types for each path segment. This PR rework the object name to allow different types for each path segment.Examples this PR will make it easier to support:
IDENTIFIERclause. Example:SELECT * FROM myschema.IDENTIFIER(:mytab). The(:mytab)is wrongly parsed right now asTableFunctionArgs. More details: https://docs.databricks.com/en/sql/language-manual/sql-ref-names-identifier-clause.htmlSELECT * FROM db..table_name. This indicates that use of default schemaPUBLIC. With this PR, we can useDefaultSchemavariant for the path segment instead of using empty identifier. More details: https://docs.snowflake.com/en/sql-reference/name-resolution#resolution-when-schema-omitted-double-dot-notationMost changes are mechanical except couple of locations I commented on below, in addition to the
ast/mod.rs.