Make SQL AT unnesting use 0-based explode ordinals

[g31pranjal]

EXPLODE WITH ORDINALITY produced 1-based ordinals, matching what SQL AT exposes. UnnestStoredRecordPlan, inside the record layer that reasons about a position within a repeated field is 0-based though. Hence, this plan, wanting to describe those positions in terms of an explode's ordinal, had to subtract the one back off.

#4625 adds support for 0-based ordinals. This PR enables that for Logical plans, which also then adds the one where it binds the AT alias. AT stays 1-based per the standard (Foundation, Section 4.10.2).

Compatibility

This is a breaking change, change but does not hamper compatibility. Previously generated plans, which have 1-based ordinals, still work since the planner are able to interpret both the variants. Moving forward, we want to move default (unset) case to be 0-based, while support the true case for the flag. Then, we can cleanup the flag.

Follow-ups

• ArithmeticValue always reports a nullable result type, even when both operands are not nullable #4622 — ArithmeticValue reports a nullable result type even when both operands are not nullable, so the AT ordinal is nullable while the column is declared not-nullable.
• Cost model scores a nested data access the same as an unnested one, so an IN-join can be chosen over a single scan #4621 — the cost model scores a data access nested under an IN-join the same as an unnested one, which is what lets the IN plan in array-join-at.yamsql flip to scanning the table once per IN-list element.

[robert-brunel]

Is the return type of the arithmetic expression now nullable or not-nullable? We’d want it to stay not-nullable.

[g31pranjal]

Unfortunately, it is nullable. ArithmeticValue always produce nullable type. That seems to be true for all operable values it seems. This seems in line with the 3-valued logic, however, we can do a better job at inferring the types correctly based on the inputs. Opened an issue about it #4622

[robert-brunel]

Not a blocker for this PR, but this plan change is a regression. Instead of one SCAN+EXPLODE, we’re now doing an EXPLODE and then one scan per EXPLODE element. However, I also see some plan improvements elsewhere where the SCAN/EXPLODE flip exactly the other way round. So this is probably another situation where the cost model doesn’t distinguish what’s better. It would be interesting to figure out which of the tie-breakers causes those plan changes, or if it’s just the hash codes changing. Maybe we can add a tie-breaker then that reliably prefers the plans with the SCAN outside.

Not in this PR of course, but could you please look at it briefly and open a GitHub issue about it?

[g31pranjal]

Opened #4621

[g31pranjal]

Folded into #4625: the ordinal base is now switched for SQL AT in the same change that introduces it, so this pull request has nothing left of its own. The AT queries stay restricted to the current version there, for the same reason they were here.

[github-actions]

📊 Metrics Diff Analysis Report

Summary

• New queries: 0
• Dropped queries: 0
• Plan changed + metrics changed: 0
• Plan unchanged + metrics changed: 0

ℹ️ About this analysis

This automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:

• New queries: Queries added in this PR
• Dropped queries: Queries removed in this PR. These should be reviewed to ensure we are not losing coverage.
• Plan changed + metrics changed: The query plan has changed along with planner metrics.
• Metrics only changed: Same plan but different metrics

The last category in particular may indicate planner regressions that should be investigated.