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/
