public inbox for [email protected]
help / color / mirror / Atom feedFrom: Henson Choi <[email protected]>
To: jian he <[email protected]>
Cc: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Row pattern recognition
Date: Fri, 19 Jun 2026 21:08:19 +0900
Message-ID: <CAAAe_zAsqKocS-Mfj2aSnJBhVyHgHUzp_TUOzJRrZR8kYsn_Rg@mail.gmail.com> (raw)
In-Reply-To: <CACJufxG6rKfd0WtsVZgzcoh8vOEwo_8UDWkuOd888ATavNv_uw@mail.gmail.com>
References: <CAAAe_zAZDuHSiVGvz9c6h=Pe=aN+FKZOrdNPfbTOk3XV+WFKYQ@mail.gmail.com>
<CAAAe_zDz3z2Paidk3jHOm9S3eMVLoXRxK0Lyo=5i_9-EfSH7fA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CACJufxFnwdQSApt2vWwYCd0gtf+JjFDxT2hbxHi=+dhFJc+-1g@mail.gmail.com>
<CAAAe_zATnkqsbLYDj8MJV1TriX9Wi0wShDg3nK3qYpiupKwhFA@mail.gmail.com>
<CAAAe_zBL+J0AYmvmcJQT7Q-gp5aRH0deJ7SE7-N21g4hWExyJw@mail.gmail.com>
<CACJufxHJFNBJ0vHCCLestWV5b7DF5e4VzfmovqGKBGgqg+rcGA@mail.gmail.com>
<CAAAe_zBY0rrgf+tKXMUc-Y3nDDD69hddRBKopEKAZobhY=Cy-Q@mail.gmail.com>
<CAAAe_zDYxq0d3exCDwvKncD0kaL2uehDir6HXo4r5DXMitKrSg@mail.gmail.com>
<CACJufxG57=ddtbN=5RZCzhxWDYXvocKmB7NtZy+DoqZuhxb_DA@mail.gmail.com>
<CAAAe_zB4TMHnpaOrwYp7dKs553q2474ZXRytGfYOfYp4DdrgiQ@mail.gmail.com>
<CACJufxFAQhbOD9EVCTAy-VwDbG4446N10GsxCcgdpFnjHO1Efw@mail.gmail.com>
<CACJufxG6rKfd0WtsVZgzcoh8vOEwo_8UDWkuOd888ATavNv_uw@mail.gmail.com>
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
view thread (136+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Row pattern recognition
In-Reply-To: <CAAAe_zAsqKocS-Mfj2aSnJBhVyHgHUzp_TUOzJRrZR8kYsn_Rg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox