[doc] STRUCT_ELEMENT example in 3.x/2.1: undefined table + outdated struct display format

[boluor]

Page

STRUCT_ELEMENT function reference — version-3.x and version-2.1, EN + ZH:

• versioned_docs/version-3.x/sql-manual/sql-functions/scalar-functions/struct-functions/struct-element.md
• versioned_docs/version-2.1/.../struct-element.md (+ the two i18n/zh-CN copies)

Two problems with the second example

select struct_col, struct_element(struct_col, 'f1') from test_struct;

1. test_struct is never created. The page has no CREATE TABLE/INSERT for test_struct, so copy-pasting the example fails with table does not exist.

2. The printed output uses an outdated STRUCT display format. The doc shows structs rendered positionally:

| struct_col            | ... |
| {1, 2, 3, 4, 5}       |   1 |
| NULL                  | NULL|
| {1, NULL, 3, NULL, 5} |   1 |

But current Doris (verified on 3.1.4 and 2.1.11) renders STRUCT columns as JSON with field names:

| {"f1":1, "f2":2, "f3":3, "f4":4, "f5":5}     | 1 |
| {"f1":1, "f2":null, "f3":3, "f4":null, "f5":5} | 1 |

So even after defining test_struct, the struct_col column in the documented output is unreproducible as written — the example is stale relative to the actual struct rendering on these release lines.

Suggested fix

Add a CREATE TABLE test_struct (...) / INSERT setup block and update the example's expected output to the current JSON struct rendering ({"f1":1, ...}, nested null lowercase). I verified that a 5-row struct<f1..f5:bigint> table reproducing the row values ({1,2,3,4,5}, {1,1000,10000000,100000000000,100000000000}, {5,4,3,2,1}, a NULL row, and {1,null,3,null,5}) yields struct_element(struct_col,'f1') = 1, 1, 5, NULL, 1 exactly — only the raw struct_col rendering needs the format update.

I'm intentionally leaving this out of the phantom-table-setup PR series because it's more than a missing-table fix — it requires changing the documented output to match current struct rendering, which is an editorial call on these older release lines.

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_bd8cae3faa79

Initial analysis:

This looks like a valid documentation issue, not a STRUCT_ELEMENT runtime bug.

I checked the current website source for the four scoped pages:

• versioned_docs/version-3.x/sql-manual/sql-functions/scalar-functions/struct-functions/struct-element.md
• versioned_docs/version-2.1/sql-manual/sql-functions/scalar-functions/struct-functions/struct-element.md
• i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/sql-manual/sql-functions/scalar-functions/struct-functions/struct-element.md
• i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/sql-manual/sql-functions/scalar-functions/struct-functions/struct-element.md

All four still have the second example querying test_struct without a setup block, and all four still show positional struct output such as {1, 2, 3, 4, 5}.

I also checked the Doris code path for the mentioned release lines. In both 2.1.11 and 3.1.4, struct JSON serialization writes object-style output with explicit field names, while struct_element resolves the requested field by name or 1-based position and returns the child column. That matches the reporter's observation that the function result is fine and the stale part is the displayed struct_col value in the docs.

Missing information:

• No product logs or profiles are needed for a docs-only fix.
• For a PR, it would still be useful to include one exact SQL transcript from the target release line(s), because whitespace in the displayed struct string can depend on the client/output path.

Suggested next step:

• Update the EN and ZH version-3.x and version-2.1 pages together.
• Add a CREATE TABLE test_struct (...) and INSERT setup block before the second example.
• Update the expected output to the current object-style struct rendering with quoted field names and JSON null for nested null fields, while keeping SQL NULL for the whole nullable struct row and the extracted result.
• While touching the page, maintainers may also want to fix the existing filed_location / filed_name spelling in the syntax and parameter table, though that is separate from this issue.