Re: language cleanups in code and docs - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: language cleanups in code and docs
Date
Msg-id CABUevExqAN0Gzhkcj4E+1hZKKw_Yte8j+dFrZLB43TzFCKtJVQ@mail.gmail.com
Whole thread Raw
In response to Re: language cleanups in code and docs  (Andres Freund <andres@anarazel.de>)
Responses Re: language cleanups in code and docs  (Joe Conway <mail@joeconway.com>)
Re: language cleanups in code and docs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Tue, Jun 16, 2020 at 2:23 AM Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2020-06-15 19:54:25 -0400, Tom Lane wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
> > On 15 Jun 2020, at 20:22, Andres Freund <andres@anarazel.de> wrote:
> >> 1) 'postmaster'. As changing that would be somewhat invasive, the word
> >> is a bit more ambiguous, and it's largely just internal, I've left
> >> this alone for now. I personally would rather see this renamed as
> >> supervisor, which'd imo actually would also be a lot more
> >> descriptive. I'm willing to do the work, but only if there's at least
> >> some agreement.
>
> > FWIW, I've never really liked the name postmaster as I don't think it conveys
> > meaning.  I support renaming to supervisor or a similar term.
>
> Meh.  That's carrying PC naming foibles to the point where they
> negatively affect our users (by breaking start scripts and such).
> I think we should leave this alone.

postmaster is just a symlink, which we very well could just leave in
place... I was really just thinking of the code level stuff. And I think
there's some clarity reasons to rename it as well (see comments by
others in the thread).


Is the symlink even used? If not we could just get rid of it. 

I'd be more worried about for example postmaster.pid, which would break a *lot* of scripts and integrations. postmaster is also exposed in the system catalogs.


--

pgsql-hackers by date:

Previous
From: "李杰(慎追)"
Date:
Subject: 回复:回复:回复:how to create index concurrently on partitioned table
Next
From: Michael Paquier
Date:
Subject: Re: Physical replication slot advance is not persistent