Re: please define 'statement' in the glossary

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: petermittere(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: please define 'statement' in the glossary
Date: 2025-07-13 15:27:06
Message-ID: 270191.1752420426@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2025-07-13 15:38:31 Re: Unexpected behaviour: it was documented to return the same value
Previous Message David G. Johnston 2025-07-13 15:17:06 Re: Unexpected behaviour: it was documented to return the same value