Re: please define 'statement' in the glossary
| От | David G. Johnston |
|---|---|
| Тема | Re: please define 'statement' in the glossary |
| Дата | |
| Msg-id | CAKFQuwa2gDZTJm5hkrqubcn1=A3aTDR7HxX-NfF-9fKrp28f+A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: please define 'statement' in the glossary (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: please define 'statement' in the glossary
|
| Список | pgsql-docs |
On Mon, Jul 14, 2025 at 9:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> 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_timestamp(); commit;"
> Transaction timestamp should progress while statement timestamp should not,
> right?
AFAICT neither one progresses. I think the reason is that (1)
statement timestamp is set by arrival of the command message
and (2) transaction timestamp is set by copying statement timestamp
at the moment of beginning a transaction.
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().
But when talking about current_timestamp first and saying "Since these functions return the start time of the current transaction" it does read more as coincidence as opposed to definition.
I'm fine with this entire section assuming/stating that extended protocol is in effect and that 53.2.2.1 explains how these behave when executing a multi-statement simple protocol "script".
David J.
В списке pgsql-docs по дате отправления: