Quanlong Huang has posted comments on this change. ( http://gerrit.cloudera.org:8080/22603 )
Change subject: IMPALA-10349: Support constant folding for non ascii strings ...................................................................... Patch Set 10: (10 comments) http://gerrit.cloudera.org:8080/#/c/22603/9/common/thrift/Exprs.thrift File common/thrift/Exprs.thrift: http://gerrit.cloudera.org:8080/#/c/22603/9/common/thrift/Exprs.thrift@121 PS9, Line 121: 1: required binary value; > Ack As Michael mentioned, TStringLiteral is used in TColumn which has a 'default_value' field that is Exprs.TExpr. I see that 'default_value' is used in KuduCatalogOpExecutor in catalogd and the value must be sent from coordinators. How about creating a kudu table with default column values and altering the default value of a kudu column? If the default value has non-UTF8 characters, will that break the compatibility? If so, we'd better increase the CatalogServiceVersion in CatalogService.thrift. http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/LiteralExpr.java File fe/src/main/java/org/apache/impala/analysis/LiteralExpr.java: http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/LiteralExpr.java@303 PS10, Line 303: if (getClass() != other.getClass()) return -1; // TODO: is this a valid case? This looks weird. Do we have a JIRA to further investigate this? http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java File fe/src/main/java/org/apache/impala/analysis/StringLiteral.java: http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@24 PS10, Line 24: import java.nio.charset.CharacterCodingException; : import java.nio.charset.CoderResult; nit: not used http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@27 PS10, Line 27: import java.util.List; : import java.util.ArrayList; : import java.util.stream.Collectors; nit: not used http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@76 PS10, Line 76: Is is ok the nit: "It is ok to" ? http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@148 PS10, Line 148: //Preconditions.checkState(needsUnescaping_); Will this fail? http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@209 PS10, Line 209: hexa nit: "hex" http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@247 PS10, Line 247: Preconditions.checkState(strValue_ != null); Can we add error messages to such new Preconditions.checkState() call sites? So when it fails, we know which part is wrong in a long query. E.g. Preconditions.checkState(strValue_ != null, "non-utf8 string: %s", getNormalizedValue()); http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/analysis/StringLiteral.java@299 PS10, Line 299: nit: has an extra space http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/util/StringUtils.java File fe/src/main/java/org/apache/impala/util/StringUtils.java: http://gerrit.cloudera.org:8080/#/c/22603/10/fe/src/main/java/org/apache/impala/util/StringUtils.java@37 PS10, Line 37: Preconditions.checkState(false); : return null; Do we want to return null or throw an IllegalStateException by checkState() here? -- To view, visit http://gerrit.cloudera.org:8080/22603 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I70663457a0b0a3443e586350f0a5996bb75ba64a Gerrit-Change-Number: 22603 Gerrit-PatchSet: 10 Gerrit-Owner: Csaba Ringhofer <[email protected]> Gerrit-Reviewer: Csaba Ringhofer <[email protected]> Gerrit-Reviewer: Impala Public Jenkins <[email protected]> Gerrit-Reviewer: Michael Smith <[email protected]> Gerrit-Reviewer: Quanlong Huang <[email protected]> Gerrit-Comment-Date: Fri, 20 Jun 2025 10:07:01 +0000 Gerrit-HasComments: Yes
