After JSON_ARRAY_INTERSECT returned a NULL result, within the
table scan, all subsequent values where NULL.
The checking of null_value in Item_func_json_array_intersect::val_str
meant that after the first occurrence of null, all values
were null.
The purpose of this check started in
Item_func_json_array_intersect::prepare_json_and_create_hash
where null_value=1 was used to indicate that an object
wasn't an array. Replaced to use dedicated is_array boolean.
Reviewed by: Rucha Deodhar
The expanded_query field in optimizer trace could produce invalid JSON when
queries contained special characters. Use st_append_escaped() to properly
handle quotes, backslashes and other special characters in the output.
If st_append_escaped() fails, emit an error message in the expanded_query.
Example:
Before: "expanded_query": "select length('a') AS `LENGTH("a")`"
After: "expanded_query": "select length('a') AS `LENGTH(\"a\")`"
The output is now properly escaped and valid JSON while maintaining
readability.
Added test cases to mysql-test/main/opt_trace.test to verify the fix.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license
Analysis:
JSON_VALUE should not allow wildcard in the path since it is not supposed to
return multiple values (as per json standards). However, JSON_QUERY()
should.
Fix:
Make JSON_VALUE() return multiple error on wildcard in the path.
Add support for the SQL standard IS JSON predicate with the syntax:
expr IS [ NOT ] JSON [ { VALUE | ARRAY | OBJECT | SCALAR } ]
[ { WITH | WITHOUT } UNIQUE [ KEYS ] ]
The predicate allows checking if an expression is valid JSON
and optionally constrains the JSON type (VALUE, ARRAY, OBJECT,
SCALAR) and whether object keys are unique.
The implementation includes:
- Basic IS JSON validation
- Support for NOT operator
- Type constraints (VALUE, ARRAY, OBJECT, SCALAR)
- Unique keys constraint (WITH/WITHOUT UNIQUE KEYS)
Rename cloning methods of class Item and its descendants
in the following way:
(from) (to)
do_build_clone -> deep_copy
build_clone -> deep_copy_with_checks
do_get_copy -> shallow_copy
get_copy -> shallow_copy_with_checks
to better reflect their functionality.
Also make Item::deep_copy() and shallow_copy() protected.
Outside users should call deep_copy_with_checks()
and shallow_copy_with_checks().
Analysis:
So, there were two problems that needed to be fixed.
1) To fix the crash.
2) After fixing the crash, the result was wrong.
Reason for crash: When we pass the hash to get_intersect_between_arrays(),
We were initialially not passing it value, so the operations were not
performed correctly.
Reason for wrong result: The number of rows that it was returning were same
as that in the table, but, only the first row had correct ouput, rest of
them were NULL (it should also be the result of interection). This was
because we modified the "items" HASH by deleting the "seen" elements.
So for next rows, it did not have the elements it should have in the hash.
Fix:
1) To fix the crash: pass the HASH by reference
2) To fix incorrect result: Maintain a separate "seen" hash, if an item
is found the the "items" hash, delete it ony temporarily and put it in the
seen hash. At then end, put the items from "seen" back into "items" and
reset "seen".
The initial hard capped limit on the depth was 32. It was implemented using
static arrays of relevant type and size 32.
Hence, to implement unlimited depth, dynamic array on mem_root was
implemented which grows by 3200 as needed. Relevant arrays were replaced
with this dynamic array.
Creates new parent Item_sum_str for Item_func_group_concat and
Item_func_collect, migrating shared methods from each of those
latter classes to the former. Simultaneously, tighten up the
method scopes.
Search conditions were evaluated using val_int(), which was wrong.
Fixing the code to use val_bool() instead.
Details:
- Adding a new item_base_t::IS_COND flag which marks Items used
as <search condition> in WHERE, HAVING, JOIN ON, CASE WHEN clauses.
The flag is at the parse time.
These expressions must be evaluated using val_bool() rather than val_int().
Note, the optimizer creates more Items which are used as search conditions.
Most of these items are not marked with IS_COND yet. This is OK for now,
but eventually these Items can also be fixed to have the flag.
- Adding a method Item::is_cond() which tests if the Item has the IS_COND flag.
- Implementing Item_cache_bool. It evaluates the cached expression using
val_bool() rather than val_int().
Overriding Type_handler_bool::Item_get_cache() to create Item_cache_bool.
- Implementing Item::save_bool_in_field(). It uses val_bool() rather than
val_int() to evaluate the expression.
- Implementing Type_handler_bool::Item_save_in_field()
using Item::save_bool_in_field().
- Fixing all Item_bool_func descendants to implement a virtual val_bool()
rather than a virtual val_int().
- To find places where val_int() should be fixed to val_bool(), a few
DBUG_ASSERT(!is_cond()) where added into val_int() implementations
of selected (most frequent) classes:
Item_field
Item_str_func
Item_datefunc
Item_timefunc
Item_datetimefunc
Item_cache_bool
Item_bool_func
Item_func_hybrid_field_type
Item_basic_constant descendants
- Fixing all places where DBUG_ASSERT() happened during an "mtr" run
to use val_bool() instead of val_int().
The `Item` class methods `get_copy()`, `build_clone()`, and `clone_item()`
face an issue where they may be defined in a descendant class
(e.g., `Item_func`) but not in a further descendant (e.g., `Item_func_child`).
This can lead to scenarios where `build_clone()`, when operating on an
instance of `Item_func_child` with a pointer to the base class (`Item`),
returns an instance of `Item_func` instead of `Item_func_child`.
Since this limitation cannot be resolved at compile time, this commit
introduces runtime type checks for the copy/clone operations.
A debug assertion will now trigger in case of a type mismatch.
`get_copy()`, `build_clone()`, and `clone_item()` are no more virtual,
but virtual `do_get_copy()`, `do_build_clone()`, and `do_clone_item()`
are added to the protected section of the class `Item`.
Additionally, const qualifiers have been added to certain methods
to enhance code reliability.
Reviewer: Oleksandr Byelkin <sanja@mariadb.com>
The tests main.func_json and json.json_no_table fail on server built with
the option -DWITH_PROTECT_STATEMENT_MEMROOT=YES by the reason that a memory
is allocated on the statement's memory root on the second execution of
a query that uses the function json_contains_path().
The reason that a memory is allocated on second execution of a prepared
statement that ivokes the function json_contains_path() is that a memory
allocated on every call of the method Item_json_str_multipath::fix_fields
To fix the issue, memory allocation should be done only once on first
call of the method Item_json_str_multipath::fix_fields. Simmilar issue
take place inside the method Item_func_json_contains_path::fix_fields.
Both methods are modified to make memory allocation only once on its
first execution and later re-use the allocated memory.
Before this patch the memory referenced by the pointers stored in the array
tmp_paths were released by the method Item_func_json_contains_path::cleanup
that is called on finishing execution of a prepared statement. Now that
memory allocation performed inside the method Item_json_str_multipath::fix_fields
is done only once, the item clean up has degenerate form and can be
delegated to the cleanup() method of the base class and memory deallocation
can be performed in the destructor.
data from a table similar to other JSON functions
Analysis:
Since we are fetching values for every row ( because we are running SELECT
for all rows of a table ), correct value can be only obtained at the time of
calling val_int() because it is called to get value for each row.
Fix:
Set up hash for each row instead of doing it during fixing fields.
* invoke parent's cleanup()
* don't reinit memroot, if already inited (causes memory leak)
also move free_root() from destructor to cleanup() to not accumulate
allocations from prepare and multiple executes
