Re: language cleanups in code and docs

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: language cleanups in code and docs
Date: 2020-06-17 18:18:59
Message-ID: 20200617181859.cugssvhozpuycesm@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-06-17 13:59:26 -0400, Robert Haas wrote:
> On Mon, Jun 15, 2020 at 2:23 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > 0002: code: s/master/primary/
> > 0003: code: s/master/leader/
> > 0006: docs: s/master/root/
> > 0007: docs: s/master/supervisor/
>
> I'd just like to make the pointer here that there's value in trying to
> use different terminology for different things. I picked "leader" and
> "worker" for parallel query and tried to use them consistently because
> "master" and "slave" were being used widely to refer to physical
> replication, and I thought it would be clearer to use something
> different, so I did.

Just to be clear, that's exactly what I tried to do in the above
patches. E.g. in 0003 I tried to follow the scheme you just
outlined. There's a part of that patch that addresses pg_dump, but most
of the rest is just parallelism related pieces that ended up using
master, even though leader is the more widely used term. I assume you
were just saying that the above use of different terms is actually
helpful:

> It's confusing if we use the same word for the server from which
> others replicate, the table from which others inherit, the process
> which initiates parallelism, and the first process that is launched
> across the whole cluster, regardless of *which* word we use for those
> things. So, I think there is every possibility that with careful
> thought, we can actually make things clearer, in addition to avoiding
> the use of terms that are no longer welcome.

With which I wholeheartedly agree.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-06-17 18:33:54 Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)
Previous Message Tom Lane 2020-06-17 18:16:36 Re: language cleanups in code and docs