[subquery] Preserve COUNT semantics in scalar subquery pull-up

[Excaliiiibur]

Fixes #378

Summary

This is not an ORCA issue; it occurs in the fallback PostgreSQL optimizer rewrite path.

Fix incorrect semantics in correlated scalar aggregate subquery pull-up when target expression contains COUNT.

This risk applies not only to manual optimizer=off, but also to other cases where planning falls back from ORCA to PostgreSQL optimizer.

What Changed

In cdbsubselect.c (convert_EXPR_to_join), for COUNT-containing scalar aggregate expressions:

• use LEFT JOIN in rewrite
• replace pulled-up expression with COALESCE(agg_expr, default_expr)
• derive default_expr from empty-input aggregate defaults:
  • COUNT(...) -> 0
  • non-COUNT aggregates -> NULL (aggregate result type)

This preserves no-match semantics for both COUNT-only and mixed COUNT+other aggregate expressions.

Tests Updated

Added/updated subselect_gp regression cases for:

• count(*) + 1
• (count(*) + 1)::bigint
• case when count(*) > 0 then count(*) + 1 else 1 end
• abs(count(*) - 1)
• count(*) + coalesce(sum(...), 0)
• coalesce(count(*) + sum(...), -1)

Files

• src/backend/cdb/cdbsubselect.c
• src/test/regress/sql/subselect_gp.sql
• src/test/regress/expected/subselect_gp.out
• src/test/regress/expected/subselect_gp_optimizer.out

[Alena0704]

As I see, the case like this (SELECT COUNT(*)+1 FROM ...) is still incorrect. You should add the check that the type of expression here can be OpExpr in the is_plain_count_agg_expr function.

Is this case is reproducible for orca? we should mention it in the commit message if it isn't and only for fallback postgres optimizer (just in case).

[Excaliiiibur]

Thanks for the feedback.

I’ve updated the fix to cover non-plain COUNT expressions as well, not just plain COUNT(*). This now includes cases like count(*) + 1, casts, CASE, abs(...), and mixed expressions such as count(*) + coalesce(sum(...), 0).

Implementation-wise, for COUNT-containing scalar aggregate expressions in the fallback PostgreSQL rewrite path, we preserve no-match semantics via LEFT JOIN + COALESCE(agg_expr, default_expr), where defaults are derived as COUNT -> 0 and non-COUNT aggregates -> NULL of aggregate result type.

I also added regression coverage for these cases, including fallback-path validation with optimizer=on + ORCA fallback. So this is not ORCA-native behavior; it is specific to the fallback PostgreSQL optimizer path.

Could you please take another look?