What do you mean by consistent with the syntax in SqlBase.g4? These aren$B!G(Bt currently defined, so we need to decide what syntax to support. There are more details below, but the syntax I$B!G(Bm proposing is more standard across databases than Hive, which uses confusing and non-standard syntax.
I doubt that we want to support Hive syntax for a few reasons. Hive uses the same column
CHANGEstatement for multiple purposes, so it ends up with strange patterns for simple tasks, like updating the column$B!G(Bs type:
ALTER TABLE t CHANGE a1 a1 INT;
The column name is doubled because old name, new name, and type are always required. So you have to know the type of a column to change its name and you have to double up the name to change its type. Hive also allows a couple other oddities:
- Column reordering with FIRST and AFTER keywords. Column reordering is tricky to get right so I$B!G(Bm not sure we want to add it.
- RESTRICT and CASCADE to signal whether to change all partitions or not. Spark doesn$B!G(Bt support partition-level schemas except through Hive, and even then I$B!G(Bm not sure how reliable it is.
I know that we wouldn$B!G(Bt necessarily have to support these features from Hive, but I$B!G(Bm pointing them out to ask the question: why copy Hive$B!G(Bs syntax if it is unlikely that Spark will implement all of the $B!H(Bfeatures$B!I(B? I$B!G(Bd rather go with SQL syntax from databases like PostgreSQL or others that are more standard and common.
The more $B!H(Bstandard$B!I(B versions of these statements are like what I$B!G(Bve proposed:
ALTER TABLE ident ALTER COLUMN qualifiedName TYPE dataType:
ALTERis used by SQL Server, Access, DB2, and PostgreSQL;
MODIFYby MySQL and Oracle.
COLUMNis optional in Oracle and
TYPEis omitted by databases other than PosgreSQL. I think we could easily add
MODIFYas an alternative to the second
ALTER(and maybe alternatives like
CHANGE) and make both
ALTER TABLE ident RENAME COLUMN qualifiedName TO qualifiedName: This syntax is supported by PostgreSQL, Oracle, and DB2. MySQL uses the same syntax as Hive and it appears that SQL server doesn$B!G(Bt have this statement. This also match the table rename syntax, which uses
ALTER TABLE ident DROP (COLUMN | COLUMNS) qualifiedNameList: This matches PostgreSQL, Oracle, DB2, and SQL server. MySQL makes
COLUMNoptional. Most don$B!G(Bt allow deleting multiple columns, but it$B!G(Bs a reasonable extension.
While we$B!G(Bre on the subject of
ALTER TABLEDDL, I should note that all of the databases use
ADD COLUMNsyntax that differs from Hive (and currently, Spark):
ALTER TABLE ident ADD COLUMN qualifiedName dataType (',' qualifiedName dataType)*: All other databases I looked at use
ADD COLUMN, but not all of them support adding multiple columns at the same time. Hive requires
)enclosing the columns and uses the
COLUMNSkeyword instead of
COLUMN. I think that Spark should be updated to make the parens optional and to support both keywords,
What does everyone think? Is it reasonable to use the more standard syntax instead of using Hive as a base?
On Fri, Sep 28, 2018 at 11:07 PM Xiao Li <firstname.lastname@example.org> wrote:
Are they consistent with the current syntax defined in SqlBase.g4? I think we are following the Hive DDL syntax: https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-AlterTable/Partition/Column
Ryan Blue <email@example.com> $BP2(B2018$BG/(B9$B7n(B28$BF|<~8^(B $B2<8a(B3:47$B
I$B!G(Bm currently working on new table DDL statements for v2 tables. For context, the new logical plans for DataSourceV2 require a catalog interface so that Spark can create tables for operations like CTAS. The proposed TableCatalog API also includes an API for altering those tables so we can make ALTER TABLE statements work. I$B!G(Bm implementing those DDL statements, which will make it into upstream Spark when the TableCatalog PR is merged.
Since I$B!G(Bm adding new SQL statements that don$B!G(Bt yet exist in Spark, I want to make sure that the syntax I$B!G(Bm using in our branch will match the syntax we add to Spark later. I$B!G(Bm basing this proposed syntax on PostgreSQL.
- Update data type:
ALTER TABLE tableIdentifier ALTER COLUMN qualifiedName TYPE dataType.
- Rename column:
ALTER TABLE tableIdentifier RENAME COLUMN qualifiedName TO qualifiedName
- Drop column:
ALTER TABLE tableIdentifier DROP (COLUMN | COLUMNS) qualifiedNameList
A few notes:
qualifiedNamein these rules allows updating nested types, like
- Updates and renames can only alter one column, but drop can drop a list.
- Rename can$B!G(Bt move types and will validate that if the TO name is qualified, that the prefix matches the original field.
- I$B!G(Bm also changing ADD COLUMN to support adding fields to nested columns by using
Please reply to this thread if you have suggestions based on a different SQL engine or want this syntax to be different for another reason. Thanks!
Ryan BlueSoftware EngineerNetflix
Ryan BlueSoftware EngineerNetflix