Hi Tatsuo,

> From ISO/IEC 9075-2:2016 7.15 <window clause> General Rules:
> ...
> a) If SL does not simply contain a <window function>, then the <window
> clause> is disregarded, and the result of TE is the result of the last
> <from clause>, <where clause>, <group by clause> or <having clause> of TE.

Thank you -- this is exactly the text I was missing.  I only have ISO/IEC
19075-5 (the guidance / technical report), which describes what a window
definition does but says nothing about a window clause being disregarded
when no window function references it.  The General Rule you quote settles
it: disregarding an unused window clause is required by the standard, and
since DEFINE is part of the window clause, it is disregarded along with the
rest.  So evaluating its DEFINE -- option (b) -- would mean running a clause
the standard tells us to ignore.

> But we already pass faulty window clauses. Example:
> ... ERROR:  frame ending offset must not be negative ...
> I think if we detect faulty DEFINE in the last case, it's not only
> against the standard but against our existing behavior.

Agreed, and the parallel is convincing.  An unused window already escapes
the negative-frame-offset check, so singling out DEFINE as the one clause
that must fire regardless would be inconsistent with how the rest of an
unused window already behaves.

This also matches the planner: select_active_windows() drops any window with
no referencing WindowFunc, and its comment already cites the same <window
clause> General Rules (General Rule 4) as its basis.

Either way, the disregard rule governs only execution.  A failure raised in
the parser, transform, rewrite, or planner is a separate, static layer the
rule does not touch.  And at execution there is nothing to evaluate: an
unused window is never turned into a WindowAgg node, so its DEFINE is never
reached.

So I'm convinced -- let's keep (a), the current behavior, and I'll treat
this open question as closed, with no patch change.  For the record, the two
halves stay cleanly separated: the RPR DEFINE volatility check still visits
every window clause at preprocessing (independent of select_active_windows),
while run-time DEFINE evaluation happens only for windows that survive it.

Thanks for digging up the standard text.

Best regards,
Henson