Laurenz Albe writes:
> This thread doesn't look like we're going to find a wording that will
> make everyone happy, but I believe that this patch is a clear improvement.
Pushed with the "command message" wording. Thanks for the discussion!
regards, tom lane
On Mon, 2025-07-14 at 13:09 -0400, Tom Lane wrote:
> "David G. Johnston" writes:
> > Ok. That explains why "statement_timestamp() and transaction_timestamp()
> > return the same value during the first command of a transaction," isn't
> > just stating the obvious. transaction_timestamp() literall
On Monday, July 14, 2025, Tom Lane wrote:
> "David G. Johnston" writes:
> > If we accept that we use the words statement and command interchangeably
> > then the sole remaining use of command here sticks out because now we
> have
> > to explain why commands are different from statements. I'd ra
"David G. Johnston" writes:
> If we accept that we use the words statement and command interchangeably
> then the sole remaining use of command here sticks out because now we have
> to explain why commands are different from statements. I'd rather just
> remove the parenthetical. It's poorly cla
On Mon, Jul 14, 2025 at 10:09 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Ok. That explains why "statement_timestamp() and transaction_timestamp()
> > return the same value during the first command of a transaction," isn't
> > just stating the obvious. transaction_timestamp() literall
"David G. Johnston" writes:
> Ok. That explains why "statement_timestamp() and transaction_timestamp()
> return the same value during the first command of a transaction," isn't
> just stating the obvious. transaction_timestamp() literally returns the
> value statement_timestamp().
Right. I'm t
On Mon, Jul 14, 2025 at 9:08 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Cannot readily test this presently but I wonder what the following
> produces:
>
> > psql -c "begin; select statement_timestamp(), transaction_timestamp();
> > select statement_timestamp(), transaction_timestamp();
"David G. Johnston" writes:
> Cannot readily test this presently but I wonder what the following produces:
> psql -c "begin; select statement_timestamp(), transaction_timestamp();
> select statement_timestamp(), transaction_timestamp(); commit; begin;
> select statement_timestamp(), transaction_t
"David G. Johnston" writes:
> I dislike the word message.
> It would be nice if we could say/document: Command means top-level SQL;
> Statement references a sub-component of a command.
I think there are enough places where we use those words
interchangeably that it would be very difficult to get
On Mon, Jul 14, 2025 at 8:45 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> I would then add an example In 53.2.2.1 showing this happening using "psql
> -c"
>
>
Cannot readily test this presently but I wonder what the following produces:
psql -c "begin; select statement_timestamp(),
On Mon, Jul 14, 2025 at 8:17 AM Tom Lane wrote:
> Laurenz Albe writes:
> > On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
> >> We seldom if ever resort to including descriptions involving the fe/be
> protocol
> >> in the SQL portion of the documentation - rightly considering (IMO)
>
Laurenz Albe writes:
> On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
>> We seldom if ever resort to including descriptions involving the fe/be
>> protocol
>> in the SQL portion of the documentation - rightly considering (IMO) those to
>> be
>> implementation details (e.g., we don't
Hello,
I think you are saying that 'statement' in the documentation shall mean
'SQL statement' and not 'the time of receipt of the latest command message
from the client'.
I also think that statement_timestamp() will keep its name, even though the
name can be seen as misleading by some.
I theref
On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
> On Sun, Jul 13, 2025 at 2:57 PM Tom Lane wrote:
> > ... so concretely, about like this?
I am fine with the patch as it is.
> We seldom if ever resort to including descriptions involving the fe/be
> protocol
> in the SQL portion of th
On Sun, Jul 13, 2025 at 2:57 PM Tom Lane wrote:
> ... so concretely, about like this?
>
>
We seldom if ever resort to including descriptions involving the fe/be
protocol in the SQL portion of the documentation - rightly considering
(IMO) those to be implementation details (e.g., we don't even dir
... so concretely, about like this?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6b327d4fd81..ed30dbe7ccd 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11244,13 +11244,13 @@ now()
CURRENT_TIMESTAMP, but is
Laurenz Albe writes:
> 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.
Yeah, that seems like a good idea.
regards, tom lane
On Sun, 2025-07-13 at 11:27 -0400, Tom Lane wrote:
> Laurenz Albe 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
Laurenz Albe 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" m
On Fri, 2025-07-11 at 10:34 +, PG Doc comments form wrote:
> the glossary (https://www.postgresql.org/docs/current/glossary.html) does
> not define 'statement' but a definition would be important to understand
> other chapters such as this sentence: "statement_timestamp() returns the
> start ti
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/glossary.html
Description:
Hello,
the glossary (https://www.postgresql.org/docs/current/glossary.html) does
not define 'statement' but a definition would be important to understand
other c
21 matches
Mail list logo
