[
https://issues.apache.org/jira/browse/PHOENIX-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597876#comment-17597876
]
ASF GitHub Bot commented on PHOENIX-6764:
-----------------------------------------
stoty commented on PR #1490:
URL: https://github.com/apache/phoenix/pull/1490#issuecomment-1231679717
> 1. The new litarals don't work with BINARY ARRAYS. I suspect that this is
not a new problem, so I'm not terribly concerned about that. This may be
related to the fact the parser generates an ARRAY of VARBINARY nodes, which is
not a supported
I have changed the literals to be interpreted as BINARY instead of VARBINARY.
We can still coerce them to varbinary, but this allows using them for BINARY
ARRAYs.
I also had to change the size estimation code.
While the BINARY type is fixed length, we don't know / pass its length when
trying to estimate its size.
> Implement Binary and Hexadecimal literals
> -----------------------------------------
>
> Key: PHOENIX-6764
> URL: https://issues.apache.org/jira/browse/PHOENIX-6764
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
>
> Currently there is no sane way to specify arbitrary binary and varbinary
> values in the query string.
> They can be set as variables for preparedstatements, and if the length
> corresponds to an existing type, then some casting gymnastics can be used to
> work around the problem, but I have not found a way to write a query that
> upserts an arbitrary three byte value into a binary/varbinary.
> The SQL standard defines Binary and Hex literals in the form ofÂ
> B'01010101001...' and X'0102AAF5...'
> Implement this in the parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
