public inbox for [email protected]
help / color / mirror / Atom feedFrom: Henson Choi <[email protected]>
To: jian he <[email protected]>
To: 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: Wed, 17 Jun 2026 16:33:26 +0900
Message-ID: <CAAAe_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@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 Jian and Tatsuo,
Thanks for the patch and the careful review.
Tatsuo, item 1 below (attribute notation inside a DEFINE clause) is a
question for you; the rest is feedback on Jian's patch.
> /* arity: a value expression and an optional offset */
> Typo: arity
"arity" may be an unfamiliar term, so I'll reword the comment in plainer
language ("takes a value expression and an optional offset").
> Simplify ParseFuncOrColumn:
> It now routes to ParseRPRNavCall exclusively when ParseExprKind is
> EXPR_KIND_RPR_DEFINE and not column projection and list_length(funcname)
> == 1. Original behavior is preserved otherwise.
> Centralize error handling:
> Treat RPR navigation as FUNCDETAIL_NORMAL to reuse the common error
> handling in ParseFuncOrColumn, effectively stripping redundant error
> checks from ParseRPRNavCall.
I'd take this structural part -- it's a clear cleanup: ParseRPRNavCall
drops the duplicated decoration checks while the common path gives the
identical messages, with no change in behavior or output.
Two user-visible changes in the patch I'd rather settle on their own
before taking them:
1. Attribute notation inside a DEFINE clause, e.g. (f).prev.
The guard this change removes is one I deliberately left undecided
during development (hence the XXX comment), so I'd keep it for now and
ask here. Without it, (f).prev with no such field gives a generic
"column \"prev\" not found ..." instead of the dedicated "cannot use
row pattern navigation function PREV in attribute notation". Three
options:
(a) Treat (f).prev as an ordinary function (prev(f)), the same as
outside a DEFINE clause -- which is what the patch does.
(b) Treat (f).prev as the navigation function -- read the attribute
notation as navigation. An ordinary function of that name is still
reachable as public.prev(...).
(c) Reject the ambiguous (f).prev with a dedicated error (what is
currently committed), rather than resolving it one way or the
other.
My own leaning is actually (a) -- it keeps attribute notation behaving
the same inside and outside a DEFINE clause. (c) is what's in the tree
now, and either way it changes the user-visible error and SQLSTATE, so
I'd rather settle this explicitly than let the refactor decide it
silently. Tatsuo, what do you think?
2. The offset type-mismatch message.
The patch rephrases
offset argument of %s must be type bigint, not type %s
to
%s offset argument of type %s cannot be coerced to the expected
bigint (+ a hint)
The behavior is identical, so I'd keep the original wording. "argument
... must be type X, not type Y" is the established phrasing -- it's what
coerce_to_boolean() produces, and the non-boolean DEFINE error in this
same feature already uses it. Rewording only the offset message would
be inconsistent with that, for no behavioral gain.
One small process note: for patches that aren't really being proposed to
the list yet -- ones still under review, or throwaway implementations
written just to analyze a problem -- could you send them off-list or as a
pull request instead? That keeps the thread focused on what's actually
being proposed for the patch.
Best regards,
Henson
view thread (129+ messages) latest in thread
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_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@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