public inbox for [email protected]
help / color / mirror / Atom feedFrom: 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]
Cc: [email protected]
Subject: Re: Row pattern recognition
Date: Fri, 19 Jun 2026 08:07:53 +0800
Message-ID: <CACJufxH_Z5aaYEir3=GHoZu-0pKzQdScu85LgCm1C8n=oQo=4Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACJufxFAQhbOD9EVCTAy-VwDbG4446N10GsxCcgdpFnjHO1Efw@mail.gmail.com>
<CACJufxG6rKfd0WtsVZgzcoh8vOEwo_8UDWkuOd888ATavNv_uw@mail.gmail.com>
<CAAAe_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@mail.gmail.com>
<[email protected]>
On Thu, Jun 18, 2026 at 5:50 PM Tatsuo Ishii <[email protected]> wrote:
>
> Hi Henson,
>
> > 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.
>
> > 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?
>
ParseFuncOrColumn cleanly handles (f).prev by translating it to prev(f) as a
regular function call. However, if a dedicated window navigation function
exists, this translation creates ambiguity — it becomes unclear whether prev(f)
is window navigation or a normal function call.
Cases with additional dots (e.g., public.prev(arg)) should also be
treated as normal
function calls, IMHO.
As a result, only prev(arg) and prev(arg, offset) are recognized as special
window navigation syntax, despite being visually identical to a function call.
Summary:
Dedicated window navigation functions should be removed entirely. Window
navigation should be limited to a single syntactic form (no dots) — one that
*looks* like a function call but is parsed as syntax.
This is not unprecedented; there are many existing cases where something appears
to be a function call but is actually a syntax form, for example:
SELECT json_object('{}');
json_object
-------------
{}
(1 row)
SELECT public.json_object('{}');
ERROR: function public.json_object(unknown) does not exist
LINE 1: SELECT public.json_object('{}');
^
So I think in the DEFINE context, it makes sense for some form that
looks like a function call to actually be syntax.
view thread (136+ 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: <CACJufxH_Z5aaYEir3=GHoZu-0pKzQdScu85LgCm1C8n=oQo=4Q@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