HIVE-29310: Type casting problem in the variant_get UDF

[deniskuzZ]

What changes were proposed in this pull request?

Create the ObjectInspector according to the specified target type

Why are the changes needed?

Filter on non-String value fails

Does this PR introduce any user-facing change?

No

How was this patch tested?

qtest

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ayushtkn]

Thanx @deniskuzZ for the fix, the prod changes looks good. I think it isn't filtering broken, it is the UDF broken in case of type casting.

this query will fail without the fix, nothing around filtering

select try_variant_get(parse_json('{"a": 1}'), '$.a', 'int')

we must change the title to reflect that and maybe rather than testing the filtering, we might add tests around different types of casting.

Regarding filtering, I tried this

SELECT
  try_variant_get(data, '$.name') AS name,
  try_variant_get(data, '$.age', 'int') AS age,
  try_variant_get(data, '$.address.city') AS city
FROM variant_filter_basic
WHERE CAST(try_variant_get(data, '$.age') AS INT) >= 30;

this works, so filtering isn't broken, the UDF cast functionality is broken

[deniskuzZ]

@ayushtkn, @difin should we include this in 4.2? there is already a blog by Ayush on this, so probably we don't want for users to encounter this issue

[ayushtkn]

If possible to include, it would be very nice

[deniskuzZ]

If possible to include, it would be very nice

please +1, or i need to fix something (updated the title)?

btw it didn't fail in variant_type.q. I don't have exception at hand but it was failing because constant in predicate and value had different types.

SELECT
    variant_get(data, '$', 'int') as as_int,
```

[ayushtkn]

LGTM