[Question] Does Doris 3.x officially support element_at() on VARIANT columns? (Documented in 4.x but missing from 3.x docs)

[Sevody]

Question

Is element_at(variant_col, 'key') an officially supported way to access sub-fields of a VARIANT column on Doris 3.x (3.1.x in particular)?

The function works correctly on our 3.x cluster, but I cannot find it in the 3.x docs and want to confirm whether relying on it in production is safe.

Background — why I cannot use the standard v['key'] subscript

I'm building a tool that parses Doris SQL using pingcap/parser (TiDB's MySQL-compatible parser; Doris is MySQL wire-compatible, so it's a natural choice).

• pingcap/parser does not recognize the v['key'] / v["a"]["b"] subscript syntax that Doris uses for VARIANT access — parsing fails.
• It does parse element_at(v, 'key') cleanly as a normal function call.

So element_at is the only viable path for me to programmatically generate VARIANT-access SQL without forking the parser.

What I have already checked

Source	Result
Doris 4.x docs	element_at is documented for VARIANT
Doris 3.x docs	No element_at page under variant-functions that I can find
Doris 3.x cluster (actual run)	SELECT element_at(v, 'a') and element_at(element_at(v,'a'),'b') both return correct results
Source code (PR #28484, merged Dec 2023 to branch-2.1)	Adds ElementAtToSlotRefRule that rewrites chained element_at calls into a SlotRef with
subColPath, enabling sub-column pruning

So it looks like the capability has been there since 2.1, and 3.x inherits it — just undocumented on the 3.x doc site.

Concrete questions

1. Is element_at(variant_col, key) officially supported and stable on the 3.x release line (3.1.x specifically)?
2. Does it get the same sub-column pruning / predicate pushdown treatment as the v['a']['b'] subscript syntax (per PR [Feature](Variant) Implement variant new sub column access method #28484)?
3. Is its absence from 3.x docs intentional (i.e. discouraged), or just a documentation gap that could be backported from 4.x?
4. Any known limitations vs. the bracket syntax — e.g. composing with CAST, predicate pushdown into inverted indexes, or sparse-column path resolution?

Why this matters

If element_at is fully equivalent to the bracket syntax on 3.x, I can rely on it in our SQL generator today. If the bracket syntax is the only intended public API on 3.x, I will need to either fork the
parser or defer the feature until we upgrade to 4.x.

Thanks!

Environment: Doris 3.1.x (FE + BE), VARIANT columns created with default settings.