Alex Behm has posted comments on this change. ( http://gerrit.cloudera.org:8080/10030 )
Change subject: IMPALA-6451: AuthorizationException in CTAS for Kudu tables ...................................................................... Patch Set 2: (1 comment) http://gerrit.cloudera.org:8080/#/c/10030/2/fe/src/main/java/org/apache/impala/analysis/CreateTableStmt.java File fe/src/main/java/org/apache/impala/analysis/CreateTableStmt.java: http://gerrit.cloudera.org:8080/#/c/10030/2/fe/src/main/java/org/apache/impala/analysis/CreateTableStmt.java@68 PS2, Line 68: private boolean kuduMasterHostsPropAdded_; This flag is extremely specific and I think it adds to the reset/re-analyze confusion. Assuming I understand the predicament correctly, I think the real issue is that we do not distinguish between table properties added by the user in the SQL and table properties generated as part of analysis. I think we should separate those properties. When we reset() we can wipe those table properties that were generated during analysis. In toThrift() we combine the user-specified properties and the generated properties. Notice that https://gerrit.cloudera.org/#/c/8820/ has a similar issue with the generated Kudu table name. Ideally, we would clean that up too to follow my proposed cleaner fix. I think if we had followed my suggestion above in 8820, then the bug in this JIRA would not exist. -- To view, visit http://gerrit.cloudera.org:8080/10030 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Iac3bbe4dceb80dfefd9756bc322f8c10ceab9f49 Gerrit-Change-Number: 10030 Gerrit-PatchSet: 2 Gerrit-Owner: Fredy Wijaya <fwij...@cloudera.com> Gerrit-Reviewer: Adam Holley <g...@holleyism.com> Gerrit-Reviewer: Alex Behm <alex.b...@cloudera.com> Gerrit-Reviewer: Fredy Wijaya <fwij...@cloudera.com> Gerrit-Comment-Date: Thu, 12 Apr 2018 19:58:46 +0000 Gerrit-HasComments: Yes