You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Hans Zeller (JIRA)" <ji...@apache.org> on 2016/05/20 00:49:13 UTC

[jira] [Updated] (TRAFODION-1174) LP Bug: 1444134 - Change CompDecode logic for VARCHAR not to expect the length field at the start of the buffer

     [ https://issues.apache.org/jira/browse/TRAFODION-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hans Zeller updated TRAFODION-1174:
-----------------------------------
    Issue Type: Improvement  (was: Bug)

> LP Bug: 1444134 - Change CompDecode logic for VARCHAR not to expect the length field at the start of the buffer
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: TRAFODION-1174
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1174
>             Project: Apache Trafodion
>          Issue Type: Improvement
>          Components: sql-exe
>            Reporter: Hans Zeller
>            Assignee: Hans Zeller
>            Priority: Minor
>
> As part of the fix for bug 1442932 and bug 1442966, we changed CompEncode that it no longer puts a VC length indicator with the max value in front of the buffer. We need to make a corresponding change to CompDecode in the long term.
> Before fixing this bug, the code should still work, since we don't actually have a case where we encode a buffer with CompEncode and then try to decode it with CompDecode. The only two cases where we use CompDecode are for serialized columns, which do not include VARCHARs and for converting HBase region keys into ItemExprs in getRangePartitionBoundaryValuesFromEncodedKeys() in file sql/optimizer/NATable.cpp. In the latter we have code to set up the length field, which we need to remove once we fix this bug.



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