Re: Confusing terminology

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Confusing terminology
Дата
Msg-id 9397.1011382946@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Confusing terminology  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Confusing terminology
Re: Confusing terminology
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> In particular, I have four examples in mind:

> [ "postmaster" and "backend" -> "server" and "session" ]

I think we should use "postmaster" when we are specifically discussing
the parent daemon process as distinguished from its children, and
"backend" when we are specifically describing a child process as
distinguished from its parent and siblings.  "Server" is fine in any
context where you just mean "that software at the other end of the wire
from the client".  Look at it this way: if Postgres were implemented as
a monolithic server process, would your documentation still be correct
and sensible?  If so, say "server".  Use the other two terms when you
need to distinguish the parts.  Example:
After receiving a connection request, the postmaster spawnsa backend process to handle that client session.

While this is certainly project-specific language, it's useful to people
who may actually have to look at the code; and if they're reading
documentation that is talking about the parts of the server in the first
place, they're not that far away from wanting to look at code.  I don't
think that
After receiving a connection request, the server spawnsa session process to handle that client session.

is an improvement --- it seems more to have reduced the concept to a
tautology.  (Also, as seen here, I don't care for using "session"
to describe a process.  A session is a different sort of animal.)

> "tuple" is described in one place as "A tuple is an individual state of a
> row; each update of a row creates a new tuple for the same logical row."
> This definition is inconsistent with common usage -- and even the rest of
> the manual.

Give us "common usage" that distinguishes these two concepts, please.
I agree that we've not been consistent, but unless someone lays down
a clear definition for everyone to follow, it won't get better.

Maybe it's time for someone to prepare an "official" glossary that sets
out all these terms carefully, so that people will have something to
refer to when they're trying to pick a word to use.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yasuo Ohgaki
Дата:
Сообщение: Re: Ignore this one ...
Следующее
От: Bear Giles
Дата:
Сообщение: user types API wish list