Re: Confusing terminology - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Confusing terminology
Date
Msg-id 9397.1011382946@sss.pgh.pa.us
Whole thread Raw
In response to Confusing terminology  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Confusing terminology  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Confusing terminology  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Yasuo Ohgaki
Date:
Subject: Re: Ignore this one ...
Next
From: Bear Giles
Date:
Subject: user types API wish list