src/backend/parser/parse_func.c

Add to src/test/regress/sql/rpr.sql (and matching .out), against an existing RPR table such as stock/price-bearing table used elsewhere in the file.
Use a numeric offset literal, which is the cleanest deterministic case:

-- negative test: offset argument type with no implicit cast to bigint
SELECT company, tdate, price, count(*) OVER w
FROM stock
WINDOW w AS (
PARTITION BY company
ORDER BY tdate
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN (A B+)
DEFINE B AS price > PREV(price, 1.5)
);

Expected .out (do not wrap in DO block):
ERROR:  offset argument of PREV must be type bigint, not type numeric
LINE n:
DEFINE B AS price > PREV(price, 1.5)
                                          ^

Notes / caveats verified:
1. The decimal constant 1.5 is typed numeric (not float8);
numeric->int8 is assignment-context only, so COERCION_IMPLICIT returns NULL -> exact lines hit.
Good.
2. An alternative offset PREV(price, 'x') also reaches the branch, BUT a bare 'x' is UNKNOWNOID: coercion of unknown to int8 also returns NULL, and the message would read "not type unknown" -- usable but less intuitive;
if a text type is wanted use PREV(price, 'x'::text) which yields "not type text" (text has no cast to int8 at all).
Prefer the numeric 1.5 form for clarity and determinism.
3. Use the actual table/column names already present in rpr.sql (e.g. the 'stock'/'company'/'price'/'tdate' fixtures) so the parser reaches the
DEFINE walk;
the error is raised at parse-analysis of the nav call regardless of data, so no specific rows are required.

Confirmed reachable and testable.
Lines 2207-2212 fire when a 2-arg nav call's explicit offset has a type lacking an IMPLICIT cast to int8. I verified the code (parse_func.c:2195-2216): nargs==2 with offtype != INT8OID calls coerce_to_target_type with COERCION_IMPLICIT/COERCE_IMPLICIT_CAST;
a NULL result raises the ereport.
I confirmed via pg_cast.dat that numeric->int8 has castcontext 'a' (assignment-only), so COERCION_IMPLICIT rejects it and returns NULL -> error fires.
I grepped every 2-arg nav call in rpr.sql: all offsets are int4 literals, random()::int (int4), int4-returning subqueries, NULL::int8, untyped NULL, or params -- none are numeric/float/text, so this branch is genuinely uncovered.
The decimal literal 1.5 is typed numeric in PostgreSQL, so PREV(price, 1.5) deterministically drives execution through these exact lines. format_type_be(numeric) yields "numeric" and the hardcoded "bigint" string makes the expected message exact.