Re: Confusing terminology - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Re: Confusing terminology |
Date | |
Msg-id | Pine.LNX.4.30.0201181605390.708-100000@peter.localdomain Whole thread Raw |
In response to | Re: Confusing terminology (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Confusing terminology
|
List | pgsql-hackers |
Tom Lane writes: > >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". That was exactly my thought. > Use the other two terms when you need to distinguish the parts. > Example: > > After receiving a connection request, the postmaster spawns > a backend process to handle that client session. This is OK, because it's true: There's a new process and it's at the backend side of the wire. (Actually, a session is something that exists between a client and a server.) What I don't like is language like "how many backends are active on this database?" -- It's one: PostgreSQL. It would be correct to say "how many (PostgreSQL) backend *processes* are active...", or maybe just "how many clients are connected to this database". > 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. Right, but there are only specific chapters in the documentation that talk about this. > > "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. The libpq API uses tuple to mean row (and field to mean column). Other APIs like pgtcl and libpq++ have copied that. I think that that's more common usage than xmin and xmax. > 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. I think it's OK to use tuple == row, and "row state" or "tuple state" when you're talking about MVCC (which is only rarely done anyway). A row can have more than one state at the same time under MVCC, but a row can have more than one tuple??? > 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. Yeah, I think I'd like to set something like this up as part of the program message style guide that I've talked about recently. -- Peter Eisentraut peter_e@gmx.net
pgsql-hackers by date: