This is an automated email from the ASF dual-hosted git repository.
yiguolei pushed a commit to branch branch-4.1
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/branch-4.1 by this push:
new c779dc5c7b8 branch-4.1: [test](jdbc) Assert SQL Server bit IN pushdown
form and make filter checks selective (#64772)
c779dc5c7b8 is described below
commit c779dc5c7b884bda255a992d93754e750355d961
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Wed Jun 24 17:19:25 2026 +0800
branch-4.1: [test](jdbc) Assert SQL Server bit IN pushdown form and make
filter checks selective (#64772)
### What problem does this PR solve?
Issue Number: #64464
Related PR: #64757 (the branch-4.1 fix this follows up on)
Problem Summary:
Test-only follow-up to #64757 (already merged into `branch-4.1`),
addressing review feedback on the SQL Server `bit` pushdown regression
test.
The merged test executed `select * from test_binary where bit_value in
('1', '0')` without asserting the pushed-down form, and because the IN
list covers every value of a `bit` column it matched all rows — so it
would still pass if the IN predicate were dropped, or rendered with
`TRUE`/`FALSE` instead of `1`/`0`.
This PR:
- adds an `explain` assertion that the pushed remote SQL renders the IN
with integer literals (`[bit_value] IN (1, 0)`);
- replaces the non-asserting executions with selective `order_qt` cases
(`= '0'` -> id=1, `= '1'` -> id=2,3) that fail if the filter is not
applied, with matching `.out` baselines.
No production code change — the boolean pushdown fix itself already
landed in `branch-4.1` via #64757.
### Release note
None
### Check List (For Author)
- Test
- [x] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test.
- Behavior changed:
- [x] No.
- [ ] Yes.
- Does this need documentation?
- [x] No.
- [ ] Yes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
---
.../jdbc/test_sqlserver_jdbc_catalog.out | 12 +++++++++++
.../jdbc/test_sqlserver_jdbc_catalog.groovy | 25 ++++++++++++++--------
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git
a/regression-test/data/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.out
b/regression-test/data/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.out
index 368a7b99390..3069fb1904f 100644
---
a/regression-test/data/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.out
+++
b/regression-test/data/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.out
@@ -184,6 +184,18 @@ varbinary_value varbinary(20) Yes true \N
2 true 0x4D616B6520446F72697320477265617421000000
0x4D616B6520446F72697320477265617421
3 true 0x4D616B6520446F72697320477265617421000000
0x4D616B6520446F72697320477265617421
+-- !bit_eq_false --
+1 false
+
+-- !bit_eq_true --
+2 true
+3 true
+
+-- !bit_in --
+1 false
+2 true
+3 true
+
-- !query_after_insert --
1 false 0x4D616B6520446F72697320477265617421000000
0x4D616B6520446F72697320477265617421
2 true 0x4D616B6520446F72697320477265617421000000
0x4D616B6520446F72697320477265617421
diff --git
a/regression-test/suites/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.groovy
b/regression-test/suites/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.groovy
index 684c0e0b27d..05545c18b1b 100644
---
a/regression-test/suites/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.groovy
+++
b/regression-test/suites/external_table_p0/jdbc/test_sqlserver_jdbc_catalog.groovy
@@ -142,10 +142,10 @@ suite("test_sqlserver_jdbc_catalog",
"p0,external,sqlserver,external_docker,exte
// Regression test for https://github.com/apache/doris/issues/64464
// SQL Server `bit` maps to Doris BOOLEAN, so a predicate like
`bit_value = '1'`
- // is folded to a boolean literal during analysis. When the filter is
pushed down
- // it must be rendered as an integer (`= 1` / `= 0`) for SQL Server,
never the
- // `TRUE`/`FALSE` keyword: SQL Server has no boolean literal and would
otherwise
- // report "Invalid column name 'TRUE'".
+ // is folded to a boolean literal during analysis. When the filter is
pushed down it
+ // must be rendered with integer literals (`= 1` / `= 0` / `IN (1,
0)`) for SQL Server,
+ // never the `TRUE`/`FALSE` keyword: SQL Server has no boolean literal
and would
+ // otherwise report "Invalid column name 'TRUE'".
explain {
sql("select * from test_binary where bit_value = '1'")
contains "[bit_value] = 1"
@@ -154,11 +154,18 @@ suite("test_sqlserver_jdbc_catalog",
"p0,external,sqlserver,external_docker,exte
sql("select * from test_binary where bit_value = '0'")
contains "[bit_value] = 0"
}
- // Execute the predicates end-to-end; on the buggy path these throw
- // "Invalid column name 'TRUE'" against SQL Server.
- sql """ select * from test_binary where bit_value = '1' order by id;
"""
- sql """ select * from test_binary where bit_value = '0' order by id;
"""
- sql """ select * from test_binary where bit_value in ('1', '0') order
by id; """
+ explain {
+ sql("select * from test_binary where bit_value in ('1', '0')")
+ contains "[bit_value] IN (1, 0)"
+ }
+ // Selective execution checks. At this point test_binary holds id=1
(bit 0),
+ // id=2 and id=3 (bit 1), so `= '0'` returns only id=1 and `= '1'`
only id=2,3:
+ // these fail if the pushed-down filter is dropped or applied as a
no-op. The IN
+ // predicate matches every row (a bit is always 0 or 1), so its 1/0
rendering is
+ // asserted by the explain above rather than by row selectivity.
+ order_qt_bit_eq_false """ select id, bit_value from test_binary where
bit_value = '0' order by id; """
+ order_qt_bit_eq_true """ select id, bit_value from test_binary where
bit_value = '1' order by id; """
+ order_qt_bit_in """ select id, bit_value from test_binary where
bit_value in ('1', '0') order by id; """
sql """ insert into test_binary values (4, 4, X"ABAB", X"AB") """
order_qt_query_after_insert """ select * from test_binary order by id;
"""
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
