Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/849#discussion_r89163492
--- 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 --
Should we make the output length depend on the function? And make it fixed
length? For example, https://en.wikipedia.org/wiki/SHA-2 shows that SHA224
results in 224 bits (which gives a hex string of 56 characters), SHA512 results
in 512 bits (128 characters) and so on. Oh, but you made the number of bits an
operand to the function and that could be an expression. In that case a VarChar
is warranted.
---
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.
---
