[ 
https://issues.apache.org/jira/browse/TRAFODION-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687397#comment-15687397
 ] 

ASF GitHub Bot commented on TRAFODION-2229:
-------------------------------------------

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.


> add Hashing functions to Trafodion
> ----------------------------------
>
>                 Key: TRAFODION-2229
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2229
>             Project: Apache Trafodion
>          Issue Type: Sub-task
>            Reporter: liu ming
>            Assignee: liu ming
>             Fix For: 2.1-incubating
>
>
> CRC32()       Compute a cyclic redundancy check value
> MD5() Calculate MD5 checksum
> SHA1(), SHA() Calculate an SHA-1 160-bit checksum
> SHA2()        Calculate an SHA-2 checksum



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to