zclllyybb commented on issue #65962:
URL: https://github.com/apache/doris/issues/65962#issuecomment-5057418732
Breakwater-GitHub-Analysis-Slot: slot_3187e4f7622d
This content is generated by AI for reference only.
Initial triage:
I do not think the screenshots alone are enough to confirm a Doris
wrong-result bug yet. The first screenshot uses an exact predicate:
```sql
where t.TABLE_NAME = 'dim_fn_f_month'
```
and it returns the expected columns for that exact table. The second
screenshot uses:
```sql
where t.TABLE_NAME like '%dim_fn_f_month%'
```
In SQL `LIKE`, `_` is a single-character wildcard, not a literal underscore.
So `%dim_fn_f_month%` can match other table names that contain the same letters
with any single character in each underscore position. The result grid also
appears to show a narrow/truncated `TABLE_NAME` column, so longer matching
table names may all look like `dim_fn_f_month` in the screenshot.
Code-path check on the reported 4.1.3 line:
- `information_schema.columns` is produced by the BE `SchemaColumnsScanner`.
- For `TABLE_NAME = '...'`, Nereids can push the fixed table name into
`SchemaScanNode`.
- For `TABLE_NAME LIKE ...`, the predicate remains normal SQL filtering. The
BE `LIKE` implementation converts unescaped `_` to a single-character match,
and supports escaping wildcard characters.
- The scanner pairs table names and column descriptors through FE
`describeTables()` offsets. I did not find a code change in this scanner
between 4.1.3 and current master that would obviously explain a confirmed
mismatch.
Suggested validation:
Please run a text-mode query that prints the full table name, not a
screenshot with a truncated column:
```sql
select TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, ORDINAL_POSITION
from information_schema.`columns`
where TABLE_SCHEMA = 'wu_bigdata_prd'
and TABLE_NAME like '%dim#_fn#_f#_month%' escape '#'
order by TABLE_NAME, ORDINAL_POSITION;
```
Also compare it with:
```sql
select TABLE_NAME
from information_schema.`tables`
where TABLE_SCHEMA = 'wu_bigdata_prd'
and TABLE_NAME like '%dim_fn_f_month%'
order by TABLE_NAME;
```
If the escaped query still returns rows where the full `TABLE_NAME` is
exactly `dim_fn_f_month` but `COLUMN_NAME` belongs to another table, then this
should be treated as a real `information_schema.columns` scanner correctness
bug. In that case, the next data needed is the full text result of the two
queries above, the exact Doris build commit for 4.1.3, and preferably a minimal
DDL with two similarly named tables that reproduces the mismatch.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
