You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by mb...@gmail.com on 2023/06/22 01:41:34 UTC

VARIANT and JSON data types

Hello,

 

I have a question about Calcite and fancier data types.

It looks like Calcite JSON operations are really implemented by treating
JSON as a string. I expect that this is expensive, since the string needs to
be parsed and serialized back for every operation.

 

Snowflake uses VARIANT types to represent the parsed JSON; a VARIANT is
really a dynamically-typed union type:
https://docs.snowflake.com/en/sql-reference/data-types-semistructured#label-
data-type-variant

 

Postgres has native types JSON, JSONB, and JSONPATH:
https://www.postgresql.org/docs/15/datatype-json.html

 

Is there a way to manipulate JSON more efficiently in Calcite than by just
using strings?

If there isn't, is anyone working on such a topic?

 

If there isn't anyone working on this, the next question is whether the
existing Calcite type system is rich enough to support a VARIANT-like  type,
or does the type system need to be extended?

 

Thank you,

Mihai


Re: VARIANT and JSON data types

Posted by Julian Hyde <jh...@gmail.com>.
https://issues.apache.org/jira/browse/CALCITE-4918 

> On Jun 21, 2023, at 6:41 PM, <mb...@gmail.com> <mb...@gmail.com> wrote:
> 
> Hello,
> 
> 
> 
> I have a question about Calcite and fancier data types.
> 
> It looks like Calcite JSON operations are really implemented by treating
> JSON as a string. I expect that this is expensive, since the string needs to
> be parsed and serialized back for every operation.
> 
> 
> 
> Snowflake uses VARIANT types to represent the parsed JSON; a VARIANT is
> really a dynamically-typed union type:
> https://docs.snowflake.com/en/sql-reference/data-types-semistructured#label-
> data-type-variant
> 
> 
> 
> Postgres has native types JSON, JSONB, and JSONPATH:
> https://www.postgresql.org/docs/15/datatype-json.html
> 
> 
> 
> Is there a way to manipulate JSON more efficiently in Calcite than by just
> using strings?
> 
> If there isn't, is anyone working on such a topic?
> 
> 
> 
> If there isn't anyone working on this, the next question is whether the
> existing Calcite type system is rich enough to support a VARIANT-like  type,
> or does the type system need to be extended?
> 
> 
> 
> Thank you,
> 
> Mihai
>