RepOrigin vs. replorigin

  • Jump to comment-1
    Masahiko Sawada<sawada.mshk@gmail.com>
    Jan 26, 2026, 9:25 PM UTC
    Hi all,
    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
    - RMREPLORIGINID
    - XLOG_REPLORIGIN_{SET|DROP}
    - reploriginsessionorigin
    - reploriginsessionxxx() functions
    Is there a conventional rule for choosing one over the other depending
    on context? Or should we consider unifying these naming conventions?"
    Regards,
    --
    Masahiko Sawada
    Amazon Web Services: https://aws.amazon.com
    • Jump to comment-1
      Amit Kapila<amit.kapila16@gmail.com>
      Jan 27, 2026, 11:02 AM UTC
      On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada.mshk@gmail.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

      - RMREPLORIGINID
      - XLOGREPLORIGIN{SET|DROP}
      - reploriginsessionorigin
      - reploriginsessionxxx() 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.
      --
      With Regards,
      Amit Kapila.
      • Jump to comment-1
        Peter Eisentraut<peter@eisentraut.org>
        Jan 27, 2026, 4:15 PM UTC
        On 27.01.26 12:02, Amit Kapila wrote:
        On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada.mshk@gmail.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

        - RMREPLORIGINID
        - XLOGREPLORIGIN{SET|DROP}
        - reploriginsessionorigin
        - reploriginsessionxxx() 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
        • Jump to comment-1
          Masahiko Sawada<sawada.mshk@gmail.com>
          Jan 27, 2026, 7:44 PM UTC
          On Tue, Jan 27, 2026 at 8:15 AM Peter Eisentraut <peter@eisentraut.org> wrote:

          On 27.01.26 12:02, Amit Kapila wrote:
          On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada.mshk@gmail.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

          - RMREPLORIGINID
          - XLOGREPLORIGIN{SET|DROP}
          - reploriginsessionorigin
          - reploriginsessionxxx() 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
          • Jump to comment-1
            Chao Li<li.evan.chao@gmail.com>
            Jan 27, 2026, 10:24 PM UTC
            On Jan 28, 2026, at 03:43, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
            On Tue, Jan 27, 2026 at 8:15 AM Peter Eisentraut <peter@eisentraut.org> wrote:

            On 27.01.26 12:02, Amit Kapila wrote:
            On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada.mshk@gmail.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

            - RMREPLORIGINID
            - XLOGREPLORIGIN{SET|DROP}
            - reploriginsessionorigin
            - reploriginsessionxxx() 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
            <v1-0001-Standardize-replication-origin-naming-to-use-Repl.patch>
            This patch is a pure rename from RepOriginId/InvalidRepOriginId to ReplOriginId/InvalidReplOriginId. I applied it locally, build passed, “make check” passed. And I searched over the source tree for any missing replacement and found none. So, LGTM.
            Best regards,
            --
            Chao Li (Evan)
            HighGo Software Co., Ltd.
            https://www.highgo.com/
            • Jump to comment-1
              Masahiko Sawada<sawada.mshk@gmail.com>
              Jan 28, 2026, 8:56 PM UTC
              On Tue, Jan 27, 2026 at 2:24 PM Chao Li <li.evan.chao@gmail.com> wrote:


              On Jan 28, 2026, at 03:43, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
              On Tue, Jan 27, 2026 at 8:15 AM Peter Eisentraut <peter@eisentraut.org> wrote:

              On 27.01.26 12:02, Amit Kapila wrote:
              On Tue, Jan 27, 2026 at 2:55 AM Masahiko Sawada <sawada.mshk@gmail.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

              - RMREPLORIGINID
              - XLOGREPLORIGIN{SET|DROP}
              - reploriginsessionorigin
              - reploriginsessionxxx() 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
              <v1-0001-Standardize-replication-origin-naming-to-use-Repl.patch>

              This patch is a pure rename from RepOriginId/InvalidRepOriginId to ReplOriginId/InvalidReplOriginId. I applied it locally, build passed, “make check” passed. And I searched over the source tree for any missing replacement and found none. So, LGTM.
              Thank you for reviewing the patch. Pushed.
              Regards,
              --
              Masahiko Sawada
              Amazon Web Services: https://aws.amazon.com