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