Re: Row pattern recognition

From: Henson Choi <assam258(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, li(dot)evan(dot)chao(at)gmail(dot)com
Subject: Re: Row pattern recognition
Date: 2026-06-24 07:45:13
Message-ID: CAAAe_zAjkjUZHMqu5DjgZH9ZZ6D5v4bBJy60ziwhHRoohnB7Zg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi jian,

Thanks -- this is a clean improvement, no objections. Honestly this part of
the
parser is an area where you read it better than I do, so I'm glad to defer
to
you here. Quick notes inline.

> 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.

Agreed.

> So, I tended to use coerce_to_target_type.

Agreed.

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

Agreed.

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

Agreed.

Tatsuo, this one looks good to take whenever you like.

Best,
Henson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-06-24 07:47:36 Re: bytea(uuid) missing proleakproof?
Previous Message Amit Kapila 2026-06-24 07:40:11 Re: Fix publisher-side sequence permission reporting