[fix](docs) fix BITMAP_AGG example setup: k5 overflows BIGINT#3897
Closed
boluor wants to merge 1 commit into
Closed
[fix](docs) fix BITMAP_AGG example setup: k5 overflows BIGINT#3897boluor wants to merge 1 commit into
boluor wants to merge 1 commit into
Conversation
The dev BITMAP_AGG page declares `k5 BIGINT` in its setup table but inserts 18446744073709551615 and 18446744073709551616, which exceed the BIGINT range. The whole INSERT is rejected, leaving the table empty, so every example on the page fails. Change `k5` to VARCHAR(32) (and quote its values) so the large values are stored as written; BITMAP_AGG converts them and applies its own range rule (values < 0 or > 18446744073709551615 are dropped), reproducing the documented output. Verified end-to-end on a live master build: every example passes (EN + ZH). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
morningman
pushed a commit
that referenced
this pull request
Jun 3, 2026
Adds the missing CREATE TABLE + INSERT setup so the BITMAP_AGG and MAP_AGG examples are runnable end-to-end. - **bitmap-agg**: dev + version-3.x + version-2.1 (EN + ZH). Includes the dev k5-overflow fix (k5 `BIGINT` → `VARCHAR(32)`: the INSERT carries values `18446744073709551615/616` that overflow BIGINT and would reject the whole row, leaving the table empty; BITMAP_AGG converts the string per its domain rule, <0 or >uint64max dropped). - **map-agg**: version-3.x + version-2.1 (EN + ZH), TPC-H `nation` (25 rows). Verified end-to-end on fresh single-BE clusters (4.1.1 / 3.1.4 / 2.1.11 and local master daily build): every touched example reproduces the doc's printed output cell-for-cell. This supersedes #3897 (the dev k5 fix is folded in here so BITMAP_AGG lives in one PR). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
BITMAP_AGGpage (dev /docs/+i18n/zh-CN/.../current/) declares its setup columnk5asBIGINT:But
18446744073709551615and18446744073709551616exceed the BIGINT range, so theINSERTis rejected outright. The table ends up empty and every example on the page fails (table/data missing).Fix
Change
k5toVARCHAR(32)(and quote its values) so the large values are stored as written.BITMAP_AGGthen converts them and applies its own documented range rule — values< 0or> 18446744073709551615are dropped — reproducing the example output0,200000000000000,300000000000000,18446744073709551615. No change to the example SQL or expected outputs.This matches the column typing already used on the version-3.x / version-2.1 copies of this page.
Verification
Ran the modified page end-to-end on a fresh live master build. Every example reproduces the documented output exactly (EN + ZH, F0).
🤖 Generated with Claude Code