[
https://issues.apache.org/jira/browse/CALCITE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819886#comment-16819886
]
Julian Hyde commented on CALCITE-2985:
--------------------------------------
I'm not too worried about the size of SqlStdOperatorTable per se; I'm more
worried about coupling. Only functions that need to be in there should be in
there.
JSON functions that are in the SQL standard should clearly be in
SqlStdOperatorTable.
For JSON functions that are MySQL extensions it is less clear. I would tend to
put them into the MySQL table; but if they have irregular syntax we have a
problem, because the parser will need to make explicit calls to them, and for
that, it has to use the operator table, and we only support passing in the
standard operator table.
If it helps to put the MySQL functions in the std table for a short time, I
have no objections.
I have said elsewhere that there seems to be too much code added to the parser
for each JSON function. Having the parser do ONLY parsing and not validation -
and keeping it decoupled from the operator table and type system - is an
important principle that has served us well. We need to get back to that.
Can someone explain why, in the parser, JsonValueExpression could not be just
one kind of expression? As, for instance, an interval literal is just an
expression. If you want to add a string to an interval, the parser won't stop
you, but the validator will give an error. If we made that change,
JSON_STORAGE_SIZE would be a regular function and would need no change
whatsoever to the parser.
> Add the JSON_STORAGE_SIZE function
> ----------------------------------
>
> Key: CALCITE-2985
> URL: https://issues.apache.org/jira/browse/CALCITE-2985
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Forward Xu
> Assignee: Forward Xu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> JSON_STORAGE_SIZE(json_val)
> This function returns the number of bytes used to store the binary
> representation of a JSON document. When the argument is a JSON column, this
> is the space used to store the JSON document. json_val must be a valid JSON
> document or a string which can be parsed as one. In the case where it is
> string, the function returns the amount of storage space in the JSON binary
> representation that is created by parsing the string as JSON and converting
> it to binary. It returns NULL if the argument is NULL.
> An error results when json_val is not NULL, and is not—or cannot be
> successfully parsed as—a JSON document.
> To illustrate this function's behavior when used with a JSON column as its
> argument, we create a table named jtable containing a JSON column jcol,
> insert a JSON value into the table, then obtain the storage space used by
> this column with JSON_STORAGE_SIZE(), as shown here:
> {code:java}
> SELECT
> JSON_STORAGE_SIZE('[100, "sakila", [1, 3, 5], 425.05]') AS A,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "a", "c": "[1, 3, 5, 7]"}') AS B,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "wxyz", "c": "[1, 3, 5, 7]"}') AS C,
> JSON_STORAGE_SIZE('[100, "json", [[10, 20, 30], 3, 5], 425.05]') AS D;
> {code}
> | A | B | C | D |
> | 29 | 37 | 40 | 36 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
