-
Notifications
You must be signed in to change notification settings - Fork 612
Support redshift's columns definition list for system information functions #769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
db9df86
158afdb
fec98ef
d81d446
17e11a1
c653872
8d2ce41
4f570a7
6353d8c
4d42aa1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5356,6 +5356,7 @@ impl<'a> Parser<'a> { | |
} else { | ||
None | ||
}; | ||
let columns_definition = self.parse_redshift_columns_definition_list(&name)?; | ||
let alias = self.parse_optional_table_alias(keywords::RESERVED_FOR_TABLE_ALIAS)?; | ||
// MSSQL-specific table hints: | ||
let mut with_hints = vec![]; | ||
|
@@ -5372,11 +5373,57 @@ impl<'a> Parser<'a> { | |
name, | ||
alias, | ||
args, | ||
columns_definition, | ||
with_hints, | ||
}) | ||
} | ||
} | ||
|
||
fn parse_redshift_columns_definition_list( | ||
&mut self, | ||
name: &ObjectName, | ||
) -> Result<Option<ColsDefinition>, ParserError> { | ||
if !dialect_of!(self is RedshiftSqlDialect) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mskrzypkows I guess this could consider the GenericDialect as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These functions are specific for the Redshift: https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html so I think it's not needed for GenericDialect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know, but the Generic dialect is supposed to be the most permissive one. Unless there are syntax conflicts (e.g., accepting those would break another part of the code), I can't see why not. |
||
return Ok(None); | ||
} | ||
|
||
let fname = name | ||
.0 | ||
.last() | ||
.ok_or_else(|| { | ||
ParserError::ParserError("Empty identifier vector for ObjectName".to_string()) | ||
})? | ||
.value | ||
.to_lowercase(); | ||
|
||
if fname == "pg_get_late_binding_view_cols" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @alamb isn't this too much related to semantic logic? it isn't just a database metadata function? Is it really necessary to have that deep information? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I agree -- I would not expect this list to be hard coded. Instead I would expect any identifier to be accepted here and then the downstream crate would check against a list if it wanted. This design goal is explained in https://github.com/sqlparser-rs/sqlparser-rs#syntax-vs-semantics |
||
|| fname == "pg_get_cols" | ||
|| fname == "pg_get_grantee_by_iam_role" | ||
|| fname == "pg_get_iam_role_by_user" | ||
{ | ||
if let Ok(col_definition_list_name) = self.parse_identifier() { | ||
self.expect_token(&Token::LParen)?; | ||
let names = self.parse_comma_separated(Parser::parse_ident_pair)?; | ||
self.expect_token(&Token::RParen)?; | ||
Ok(Some(ColsDefinition { | ||
name: col_definition_list_name, | ||
args: names, | ||
})) | ||
} else { | ||
Ok(None) | ||
} | ||
} else { | ||
Ok(None) | ||
} | ||
} | ||
|
||
fn parse_ident_pair(&mut self) -> Result<IdentPair, ParserError> { | ||
Ok(IdentPair( | ||
self.parse_identifier()?, | ||
self.parse_identifier()?, | ||
)) | ||
} | ||
|
||
pub fn parse_derived_table_factor( | ||
&mut self, | ||
lateral: IsLateral, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason not to use the existing
ColumnDef
?https://github.com/sqlparser-rs/sqlparser-rs/blob/61c661c234518ae02ae2c50d317e4640e4b90e26/src/ast/ddl.rs#L479-L486
I think that would make this PR significantly shorter as well as supporting other options
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the name is misleading. I should have named it e.g.
TableAliasDefinition
, because it defines what will be a result table, what column names it will have.Like in the example:
But I think it's a good idea to use
ColumnDef
inside the vector, instead of vector ofIdentPair
s.What's your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good idea to me
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried using
ColumnDef
and failed becausename
is not a column type. It's strange, redshift doesn't define it as a keyword nor a type, but it's used in such a case. I think it's not a good idea to add it as additional type, so I'll rather back toIdentPair
, or is there a better way to handle it?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I looked at the docs for
https://docs.aws.amazon.com/redshift/latest/dg/PG_GET_GRANTEE_BY_IAMROLE.html
I see in the example it has something like
I think this PR is related to this bit of the query (note there is no comma between the call to
pg_get_grantee_by_iam_role
)I have several confusions:
Maybe someone could do some more research into what exactly this syntax construct in Redshift is called and what its rules are
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
name
type, then it has to be added to theDataType
, right?