Skip to content

[#603] Assert failure when NOT is used on functions like LEAST, GREATEST, NULLIF etc.

Narayanan Iyer requested to merge nars1/YDBOcto:octo603 into master
  • The main issue was the placement of LP_* type codes in lp_action_types.hd. Opcodes like LP_GREATEST etc. were placed after LP_ADDITION and this meant that the (LP_ADDITION > type) check done in in lp_apply_not() (in lp_make_normal_disjunctive_form.c) to filter out a whole class of logical plan types was not doing the correct filtering for a few plan codes that could be seen as operand 0 of a LP_LOGICAL_NOT plan. And this finally resulted in an assert failure.

    Those plan types are now moved to BEFORE the LP_ADDITION type. And that fixes the assert failure.

  • Took this opportunity to also move the aggregate function logical plan types even though they cannot be operand 0 of a LP_LOGICAL_NOT plan (because none of them can currently take in boolean typed operands). This is because aggregate functions are in the same class of plan types as LP_FUNCTION_CALL which can appear as operand 0 of a LP_LOGICAL_NOT plan.

  • Because of this change, an assert(LP_ADDITION <= plan->type) in lp_replace_derived_table_references.c is now fixed to instead be assert(LP_FUNCTION_CALL <= plan->type).

  • With this change, lp_apply_not() does the right thing for LP_GREATEST etc. as these opcodes now satisfy the LP_ADDITION > type check. So no more code fix was needed.

  • A new test_not_operator/TNO01 bats subtest verifies this fix by testing for various LP_ plan types.

  • This assert failure seems to show up only in Debug builds of Octo. In Release builds, there is no assert seen and the output is correct for the queries in tests/fixtures/TNO01.sql so likely no user-visible impact because of this issue or the fix.

Merge request reports