Re: Row pattern recognition

On Wed, Jun 10, 2026 at 2:10 PM Henson Choi <assam258(at)gmail(dot)com> wrote:
>
> Hi Tatsuo, Jian,
>
>
> == 2. PREV/NEXT/FIRST/LAST placeholders collide with user functions ==
>
> The nav operations are polymorphic pg_catalog functions (anyelement, OIDs
> 8126-8133) recognized by funcid in parse_func.c, which collides with
> same-name user functions.
>
> Outside DEFINE, a same-name function masks or clashes with the placeholder:
> with public.last(anyelement), SELECT last(123) fails "cannot use last
> outside a DEFINE clause"; with public.next(numeric), SELECT next(10) fails
> "function next(integer) is not unique"; and even with no user function,
> last(123) errors instead of "function last(integer) does not exist".
>
> Inside DEFINE, a same-name function with an exact-type match beats the
> anyelement placeholder, so PREV(price) silently becomes a plain FuncExpr
> instead of an RPRNavExpr -- a wrong match result with no error (reproduced
> for numeric, text and int). And ruleutils deparses a bare PREV(, so
> reparsing a view under a search_path with public.prev rebinds it (pg_dump
> is safe via search_path = '').
>
> This is original v47 design, not a regression. Per the standard,
> PREV/NEXT/FIRST/LAST are navigation operations with dedicated syntax, not
> general-namespace functions -- the collision comes from mapping them onto
> catalog functions plus search-path resolution.
>
> I haven't found a clean approach yet. Inside DEFINE these names have to be
> the navigation operation (per the standard), yet outside DEFINE they
> shouldn't shadow or break same-name user functions the way the catalog
> placeholders do -- and since the deparse output is unqualified (a bare
> PREV(...)), whatever we choose also has to round-trip cleanly. I'm not
> sure how best to reconcile those.
>
> My rough leaning is to not add catalog functions for these at all: leave
> resolution outside DEFINE exactly as it is today, and only inside DEFINE
> adjust the function-resolution path itself to recognize the navigation
> operations. But that is still quite abstract.
>
> Question: how would you approach this?
>

SELECT first_value(1);
ERROR: window function first_value requires an OVER clause
LINE 1: SELECT first_value(1);
^

select prosrc, prokind, proname from pg_proc
where proname = 'prev' or proname = 'first' or proname = 'last' or
proname = 'next';

I am wondering, why the above query result functions not makred as
window function in catalog?