On Sun, 2025-07-13 at 11:27 -0400, Tom Lane wrote: > Laurenz Albe <laurenz.a...@cybertec.at> writes: > > After looking at the code, I guess what made Tom add the remark in commit > > eaf8f312c754 was the fact that an SQL statement is not necessarily processed > > in a single go: with the extended query protocol (see chapter 52.2.3), > > there is a "parse", a "bind" and an "execute" message from the client, and > > each one sets the timestamp reported by statement_timestamp() to a new > > value. So, technically, statement_timestamp() has a different value when > > the statement is parsed than when it is executed. > > > However, what matters to the client is the value when the statement starts > > executing, because that's the value that will be reported. > > > So I'd argue that we should remove the parenthetical remark. It confuses > > more than it enlightens, and whoever needs to know that level of detail > > had better read the code anyway. > > After re-reading that text, I feel like the parenthetical remark is > fine, and the real problem is that I used "statement" and "command" > more or less interchangeably in successive sentences. Perhaps > s/command/statement/g throughout the paragraph would improve matters? > Although "statement message" doesn't feel right, so maybe leave that > one alone.
Changing "command" to "statement" would be a good move. I guess I get the remark now: it wants to say that a) statement_timestamp() shows the time when the client message that started the execution of the current SQL statement reached the server and b) the timestamp isn't reset for nested statements Perhaps the remark should say "protocol message" or "frontend-backend protocol message" to make clear that we are not talking about an SQL statement here. Yours, Laurenz Albe
