MIME-Version: 1.0
References: 
 <CACJufxFAQhbOD9EVCTAy-VwDbG4446N10GsxCcgdpFnjHO1Efw@mail.gmail.com>
 <CACJufxG6rKfd0WtsVZgzcoh8vOEwo_8UDWkuOd888ATavNv_uw@mail.gmail.com>
 <CAAAe_zDfrGSTqhgy8vOC1K6mzDsqVJGEmMy5N84G6=5EJT6--g@mail.gmail.com>
 <20260618.185007.1430819167281911424.ishii@postgresql.org>
In-Reply-To: <20260618.185007.1430819167281911424.ishii@postgresql.org>
From: jian he <jian.universality@gmail.com>
Date: Fri, 19 Jun 2026 08:07:53 +0800
Message-ID: 
 <CACJufxH_Z5aaYEir3=GHoZu-0pKzQdScu85LgCm1C8n=oQo=4Q@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: assam258@gmail.com, zsolt.parragi@percona.com, sjjang112233@gmail.com,
	vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com,
	david.g.johnston@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CACJufxH_Z5aaYEir3%3DGHoZu-0pKzQdScu85LgCm1C8n%3DoQo%3D4Q%40mail.gmail.com>
Precedence: bulk

On Thu, Jun 18, 2026 at 5:50=E2=80=AFPM Tatsuo Ishii <ishii@postgresql.org>=
 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 a=
nd
> >    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 st=
ill
> >        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 behavi=
ng
> >    the same inside and outside a DEFINE clause.  (c) is what's in the t=
ree
> >    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 =E2=80=94 it becomes unclear whe=
ther 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 ca=
ll.

Summary:
Dedicated window navigation functions should be removed entirely.  Window
navigation should be limited to a single syntactic form (no dots) =E2=80=94=
 one that
*looks* like a function call but is parsed as syntax.

This is not unprecedented; there are many existing cases where something ap=
pears
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.