Re: language cleanups in code and docs

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: language cleanups in code and docs
Дата
Msg-id CABUevExqAN0Gzhkcj4E+1hZKKw_Yte8j+dFrZLB43TzFCKtJVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: language cleanups in code and docs  (Andres Freund <andres@anarazel.de>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "李杰(慎追)"
Дата:
Сообщение: 回复:回复:回复:how to create index concurrently on partitioned table
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Physical replication slot advance is not persistent