Free RANGE frames do not validate trailing ORDER BY key types

[viirya]

Describe the bug

Describe the bug

Type validation for a free RANGE window frame only checks the first ORDER BY expression when that expression has a supported range target type.

However, every ORDER BY expression participates in peer comparison. Consequently, an unsupported type such as Map can appear as a trailing ordering key and reach execution.

The default frame for OVER (ORDER BY ...) is also a free RANGE frame, so an explicit frame declaration is not required to trigger this problem.

How to reproduce

SELECT count(*) OVER (ORDER BY i, m)
FROM (
    VALUES
        (1, map(['a'], [1])),
        (1, map(['a'], [2]))
) t(i, m);

The first ordering key, i, is supported, so planning succeeds without validating the trailing Map key.

Expected behavior

Planning should fail with an error such as:

RANGE window frames are not supported for ORDER BY type Map

All ordering keys used by a free RANGE frame should be validated because they all participate in determining peer rows.

Actual behavior

Only the first ordering key is validated. Unsupported trailing keys can reach peer comparison during execution.

This may produce incorrect window results. For example, Maps with identical keys but different values can be treated as peers even though the input sort distinguishes them.

Other unsupported nested types may instead fail during execution rather than being rejected during planning.

Root cause

coerce_window_frame obtains the range target type from only the first ORDER BY expression.

When that expression returns a target type from extract_window_frame_target_type, the code does not invoke free-range type validation for the remaining ordering expressions.

Finite-offset RANGE frames require one ordering key, but free RANGE frames allow multiple keys, making the missing trailing-key validation observable.

To Reproduce

No response

Expected behavior

No response

Additional context

No response