Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/849#discussion_r89171797
--- Diff: core/sql/optimizer/SynthType.cpp ---
@@ -1034,6 +1033,37 @@ const NAType *BuiltinFunction::synthesizeType()
}
}
break;
+
+ case ITM_SHA2:
+ {
+ ValueId vid1 = child(0)->getValueId();
+ SQLChar c1(ComSqlId::MAX_QUERY_ID_LEN);
+ vid1.coerceType(c1, NA_CHARACTER_TYPE);
+
+ const NAType &typ1 = child(0)->getValueId().getType();
+
+ if (typ1.getTypeQualifier() != NA_CHARACTER_TYPE)
+ {
+ *CmpCommon::diags() << DgSqlCode(-4067) << DgString0("SHA2");
+ return NULL;
+ }
+
+ // type cast any params
+ ValueId vid = child(0)->getValueId();
+ vid.coerceType(NA_NUMERIC_TYPE);
+ const NAType &typ2 = child(1)->getValueId().getType();
+
+ if (typ2.getTypeQualifier() != NA_NUMERIC_TYPE)
+ {
+ *CmpCommon::diags() << DgSqlCode(-4045) << DgString0("SHA2");
+ return NULL;
+ }
+
+ retType = new HEAP
+ SQLVarChar(1024, typ1.supportsSQLnull());
--- End diff --
Yes, a fixed length char would be better for a couple of reasons, other
than the varchar length overhead
a) varchars are currently blank padded when they are sent to a UDF
b) formation of a VEG with varchar columns is not enabled by default.
Since the length of the char depends on the second argument, this may mean
that
a) we need different ItemExprs for each of the new lengths that are being
added and not use a second argument OR
b) we insist that the second argument be a literal.
Often a customer will choose a SHA function with smaller length since they
want to control the amount of data being moved. Since our varchars are expanded
in certain cases it seems safer to have a fixed length here. The UDF issue may
be fixed soon, if you feel the code will be cleaner as done now, then we can
leave it as is too.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
