Re: Row pattern recognition

Hi.

``The actual mark is set to: min(lookback_mark, lookahead_mark).``
in README.rpr need update?

The attached patch is still based on
https://github.com/assam258-5892/postgres/commits/RPR.

v50-0001-Refactor-visit_nav_plan.partial
v50-0002-Refactor-visit_nav_exec.partial
v50-0003-no-need-compile-and-evaluate-offset-in-expression-evaluation.partial
v50-0004-misc.partial
v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot

The ".partial" patch, when combined, contains the same content as the
single patch (v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot).
(I first created separated patches, but then I felt the whole change
focuses on one main topic, so merging them made sense to me).

The commit message for the main patch
(v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot) is
below:
------------------------------------------------
Subject: [PATCH v51 1/1] Evaluate navigation offset once at one place

Row pattern navigation (PREV/NEXT/FIRST/LAST and their compounds) resolved
offsets (transform a expression to a int64 number) in ExecInitExprRec,
ExecEvalRPRNavSet, extract_const_offset, eval_define_offsets. Serval places
transform the same offset expression to a int64 number, that is too much!

With the attached, a single place (ExecInitWindowAgg->eval_define_offsets) to
handling this.

visit_nav_exec() now evaluates every offset expression at executor init and save
the result on the RPRNavExpr (offset / compound_offset); ExecEvalRPRNavSet()
simply reads those int64 values. This removes:

- the RPRNavOffsetKind enum and the offset/kind fields on the
WindowAgg plan node. The planner walk (visit_nav_plan /
compute_define_metadata) now only classifies match_start
dependency, which is all buildRPRPattern() needs to decide context
absorption.

- the per-invocation offset machinery in the executor: the Datum*
offset arrays in the eval step, rpr_nav_get_compound_offset(), and
the scattered NULL/negative checks, now centralized in
eval_nav_offset.

The "retain all" case (backward reach overflows int64) is encoded as the
sentinel navMaxOffset < 0 rather than an enum value; advance_nav_mark() disables
tuplestore trim on it. EXPLAIN reads the resolved offsets from the planstate
(ExecInitWindowAgg is reached for EXPLAIN without ANALYZE), so it now prints
concrete offsets instead of "runtime".

```
We must still set nav_saved_outertuple (done above) so that
EEOP_RPR_NAV_RESTORE is a harmless no-op.
```
The above in ExecEvalRPRNavSet is wrong, EEOP_RPR_NAV_RESTORE will never be a
no-op. However we can make EEOP_RPR_NAV_RESTORE no-op, so the above comments
make sense.

Rename eval_nav_offset_helper to eval_nav_offset

Based on https://github.com/assam258-5892/postgres/commits/RPR
------------------------------------------------

--
jian
https://www.enterprisedb.com/