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>
 <CACJufxH_Z5aaYEir3=GHoZu-0pKzQdScu85LgCm1C8n=oQo=4Q@mail.gmail.com>
In-Reply-To: 
 <CACJufxH_Z5aaYEir3=GHoZu-0pKzQdScu85LgCm1C8n=oQo=4Q@mail.gmail.com>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Fri, 19 Jun 2026 09:43:10 +0900
Message-ID: 
 <CAAAe_zAe8CRN-ggNhcP7b-ALiRrHxKTXBWbNVMhdW_QoO=1c4Q@mail.gmail.com>
Subject: Re: Row pattern recognition
To: jian he <jian.universality@gmail.com>, Tatsuo Ishii <ishii@postgresql.org>
Cc: 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: multipart/alternative; boundary="0000000000008b3e6a0654909452"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zAe8CRN-ggNhcP7b-ALiRrHxKTXBWbNVMhdW_QoO%3D1c4Q%40mail.gmail.com>
Precedence: bulk

--0000000000008b3e6a0654909452
Content-Type: text/plain; charset="UTF-8"

Hi Jian,

> 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.

Agreed, and that is the reason I would rather not have a dedicated
navigation function at all.  With navigation handled purely as syntax,
(f).prev never has to compete with it: attribute notation just falls
through to an ordinary function (prev(f)), the same inside and outside a
DEFINE clause.  That is Tatsuo's and my preferred option (a), so I will
settle on it.

> Cases with additional dots (e.g., public.prev(arg)) should also be treated
> as normal function calls, IMHO.

Yes.  A schema-qualified name is the explicit escape hatch to an ordinary
function; navigation is recognized only for an unqualified, single-element
name.

> 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.

Right -- that is exactly the surface I want to land on: the dotless
prev(...)/next(...)/first(...)/last(...) forms are navigation, everything
else is an ordinary function.

> 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.

That is the direction I will take the tree.  So the three of us have
converged.

> 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.

The json_object parallel is exact at the user-visible level, but I want to
flag that the implementation has to differ underneath -- and that is
actually why navigation is not done the json_object way.

json_object can live in the grammar because two constraints do not apply to
it:

  - No context restriction.  JSON_OBJECT means the same thing wherever a
    value expression is allowed, so a single keyword production in the
    shared a_expr grammar is enough.

  - The name is safe to reserve.  Making json_object a keyword costs almost
    nobody an identifier.

Row pattern navigation has both constraints:

  - It must mean navigation *only* inside DEFINE; everywhere else
    prev/next/first/last are ordinary names.  bison is LALR(1) and
    context-free, so a production cannot be conditioned on "are we inside
    DEFINE"; a_expr is shared by SELECT lists, WHERE, etc.  And a row
    pattern definition is "ColId AS a_expr", so navigation can appear
    anywhere a value expression can.  Special-casing it in the grammar
    would mean duplicating the whole a_expr tree into a second DEFINE-only
    expression grammar (or resorting to lexer feedback), which is not worth
    it.

  - The names are common.  prev/next/first/last (especially next, first,
    last) are everyday column and function names; reserving them globally
    would break existing queries.

So the plan is the opposite of a grammar keyword: parse navigation as an
ordinary FuncCall and reinterpret it in parse analysis, gated on
p_expr_kind == EXPR_KIND_RPR_DEFINE and an unqualified, single-element
name.  That keeps one expression grammar, leaves the names free everywhere
else, and confines the special meaning to exactly the DEFINE context -- the
same "looks like a function call, parsed as syntax" behavior you described,
reached by a lighter path that does not grow the keyword list.

Thanks,
Henson

--0000000000008b3e6a0654909452
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jian,<br><br>&gt; ParseFuncOrColumn cleanly handles (f)=
.prev by translating it to prev(f) as a<br>&gt; regular function call. Howe=
ver, if a dedicated window navigation function<br>&gt; exists, this transla=
tion creates ambiguity -- it becomes unclear whether<br>&gt; prev(f) is win=
dow navigation or a normal function call.<br><br>Agreed, and that is the re=
ason I would rather not have a dedicated<br>navigation function at all.=C2=
=A0 With navigation handled purely as syntax,<br>(f).prev never has to comp=
ete with it: attribute notation just falls<br>through to an ordinary functi=
on (prev(f)), the same inside and outside a<br>DEFINE clause.=C2=A0 That is=
 Tatsuo&#39;s and my preferred option (a), so I will<br>settle on it.<br><b=
r>&gt; Cases with additional dots (e.g., public.prev(arg)) should also be t=
reated<br>&gt; as normal function calls, IMHO.<br><br>Yes.=C2=A0 A schema-q=
ualified name is the explicit escape hatch to an ordinary<br>function; navi=
gation is recognized only for an unqualified, single-element<br>name.<br><b=
r>&gt; As a result, only prev(arg) and prev(arg, offset) are recognized as =
special<br>&gt; window navigation syntax, despite being visually identical =
to a function<br>&gt; call.<br><br>Right -- that is exactly the surface I w=
ant to land on: the dotless<br>prev(...)/next(...)/first(...)/last(...) for=
ms are navigation, everything<br>else is an ordinary function.<br><br>&gt; =
Summary:<br>&gt; Dedicated window navigation functions should be removed en=
tirely.=C2=A0 Window<br>&gt; navigation should be limited to a single synta=
ctic form (no dots) -- one<br>&gt; that *looks* like a function call but is=
 parsed as syntax.<br><br>That is the direction I will take the tree.=C2=A0=
 So the three of us have<br>converged.<br><br>&gt; This is not unprecedente=
d; there are many existing cases where something<br>&gt; appears to be a fu=
nction call but is actually a syntax form, for example:<br>&gt;<br>&gt; SEL=
ECT json_object(&#39;{}&#39;);<br>&gt; =C2=A0json_object<br>&gt; ----------=
---<br>&gt; =C2=A0{}<br>&gt; (1 row)<br>&gt;<br>&gt; SELECT public.json_obj=
ect(&#39;{}&#39;);<br>&gt; ERROR: =C2=A0function public.json_object(unknown=
) does not exist<br>&gt; LINE 1: SELECT public.json_object(&#39;{}&#39;);<b=
r>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^<br>&gt;<br>=
&gt; So I think in the DEFINE context, it makes sense for some form that lo=
oks<br>&gt; like a function call to actually be syntax.<br><br>The json_obj=
ect parallel is exact at the user-visible level, but I want to<br>flag that=
 the implementation has to differ underneath -- and that is<br>actually why=
 navigation is not done the json_object way.<br><br>json_object can live in=
 the grammar because two constraints do not apply to<br>it:<br><br>=C2=A0 -=
 No context restriction.=C2=A0 JSON_OBJECT means the same thing wherever a<=
br>=C2=A0 =C2=A0 value expression is allowed, so a single keyword productio=
n in the<br>=C2=A0 =C2=A0 shared a_expr grammar is enough.<br><br>=C2=A0 - =
The name is safe to reserve.=C2=A0 Making json_object a keyword costs almos=
t<br>=C2=A0 =C2=A0 nobody an identifier.<br><br>Row pattern navigation has =
both constraints:<br><br>=C2=A0 - It must mean navigation *only* inside DEF=
INE; everywhere else<br>=C2=A0 =C2=A0 prev/next/first/last are ordinary nam=
es. =C2=A0bison is LALR(1) and<br>=C2=A0 =C2=A0 context-free, so a producti=
on cannot be conditioned on &quot;are we inside<br>=C2=A0 =C2=A0 DEFINE&quo=
t;; a_expr is shared by SELECT lists, WHERE, etc.=C2=A0 And a row<br>=C2=A0=
 =C2=A0 pattern definition is &quot;ColId AS a_expr&quot;, so navigation ca=
n appear<br>=C2=A0 =C2=A0 anywhere a value expression can.=C2=A0 Special-ca=
sing it in the grammar<br>=C2=A0 =C2=A0 would mean duplicating the whole a_=
expr tree into a second DEFINE-only<br>=C2=A0 =C2=A0 expression grammar (or=
 resorting to lexer feedback), which is not worth<br>=C2=A0 =C2=A0 it.<br><=
br>=C2=A0 - The names are common. =C2=A0prev/next/first/last (especially ne=
xt, first,<br>=C2=A0 =C2=A0 last) are everyday column and function names; r=
eserving them globally<br>=C2=A0 =C2=A0 would break existing queries.<br><b=
r>So the plan is the opposite of a grammar keyword: parse navigation as an<=
br>ordinary FuncCall and reinterpret it in parse analysis, gated on<br>p_ex=
pr_kind =3D=3D EXPR_KIND_RPR_DEFINE and an unqualified, single-element<br>n=
ame.=C2=A0 That keeps one expression grammar, leaves the names free everywh=
ere<br>else, and confines the special meaning to exactly the DEFINE context=
 -- the<br>same &quot;looks like a function call, parsed as syntax&quot; be=
havior you described,<br>reached by a lighter path that does not grow the k=
eyword list.<br><br>Thanks,<br>Henson<br></div>

--0000000000008b3e6a0654909452--