| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: RepOrigin vs. replorigin |
| Date: | 2026-01-27 19:43:53 |
| Message-ID: | CAD21AoCWro9iO9s4co4MzGv+W-8c9JaS5gkAV0tiqXxE9oZ6yw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 27, 2026 at 8:15 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> 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
>
Thank you for the comments! I agree to unify the naming.
I'm going to push the attached patch, barring any objections.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Standardize-replication-origin-naming-to-use-Repl.patch | application/octet-stream | 54.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2026-01-27 19:44:36 | Re: Remaining dependency on setlocale() |
| Previous Message | Andres Freund | 2026-01-27 19:24:30 | Re: unnecessary executor overheads around seqscans |