Re: Row pattern recognition

On Wed, Jun 24, 2026 at 10:33 AM jian he <jian.universality@gmail.com> wrote:
>
> Hi.
>
> It's still based on https://github.com/assam258-5892/postgres/commits/RPR
>

    /*
     * Once the name matches we never fall back to function resolution, so any
     * decoration that does not make sense for a navigation operation is a
     * hard error.  The aggregate/window decorations (agg_star, DISTINCT,
     * WITHIN GROUP, ORDER BY, FILTER, OVER, RESPECT/IGNORE NULLS) are already
     * rejected by the common path in ParseFuncOrColumn, which treated the
     * recognized name as an ordinary function; what remains are the
     * decorations that path accepts for a plain function but a navigation
     * operation must still reject.
     */

The above comments can be deleted, ParseRPRNavCall, ParseFuncOrColumn
already have lots of comments.
Also the error check and its message are quite intuitive in ParseRPRNavCall.

coerce_to_common_type have comments:
```
 * This is used following select_common_type() to coerce the individual
 * expressions to the desired type
 ```

coerce_to_target_type comments says
```
* This is the general-purpose entry point for arbitrary type coercion
* operations.
```
So, I tended to use coerce_to_target_type.

ParseRPRNavCall ending can be simplified because coerce_to_target_type
can handle the same data type.
Therefore, `if (offtype != INT8OID)` is not necessary.

Drop the extra parentheses around ereport() argument lists, fewer
parentheses are always better for new code.



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