| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: RepOrigin vs. replorigin |
| Date: | 2026-01-27 16:15:42 |
| Message-ID: | ab3f573e-8218-4665-be62-3bb8ae0055f7@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27.01.26 12:02, Amit Kapila wrote:
> On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>
>> While reading the code in origin.c, I found the inconsistent use of
>> RepOrigin and replorigin (with an 'l') quite confusing -- especially
>> when trying to determine names for new functions or variables. For
>> instance,
>>
>> - RepOriginId
>> - InvalidRepOriginId
>>
>> - RM_REPLORIGIN_ID
>> - XLOG_REPLORIGIN_{SET|DROP}
>> - replorigin_session_origin
>> - replorigin_session_xxx() functions
>>
>> Is there a conventional rule for choosing one over the other depending
>> on context? Or should we consider unifying these naming conventions?"
>>
>
> AFAICS, most places use replorigin. So, +1 to unify the naming by
> adding 'l' to places where it is not there unless someone sees a
> theory/reason to keep them different.
agreed
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-01-27 16:16:13 | Re: pgsql: Prevent invalidation of newly synced replication slots. |
| Previous Message | Corey Huinker | 2026-01-27 16:14:12 | Re: Extended Statistics set/restore/clear functions. |