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

Reply via email to