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

Sergey Soldatov commented on PHOENIX-2934:
------------------------------------------

[~jamestaylor] sure.
I would suggest instead of copying everything from PDataType just to pad the 
result after calling super:
{noformat}
      if(actualMaxLength != null && actualMaxLength < desiredMaxLength) {
        pad(ptr,desiredMaxLength,expectedModifier);
      }
{noformat}
And it would be nice to cover this by UT with different kind of params, not 
only IT.  

Actually I also have an another (not related to this particular fix) concern 
about how we works with size of PChar. It looks strange that we let following:
{noformat}
select cast('1234234234' as char(3)) c from p;
{noformat}


> Checking a coerce expression at top level should not be necessary for Union 
> All query
> -------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-2934
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2934
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Alicia Ying Shu
>            Assignee: Alicia Ying Shu
>         Attachments: PHOENIX-2934.patch
>
>
> When working on PHOENIX-2886, found that we need special handling of coerce 
> expression. Otherwise the following query would fail.
> {code}
> create table person ( id bigint not null primary key, firstname char(10), 
> lastname varchar(10) );
> select id, cast( 'foo' as char(10)) firstname, lastname from person union all 
> select * from person;
> {code}
> Checking a coerce expression at top level should not be necessary. Need to 
> find out root cause on coerceExpression. 



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

Reply via email to