Hvordan transaction_timestamp() virker i PostgreSQL

I PostgreSQL er transaction_timestamp() funktion returnerer den aktuelle dato og det aktuelle klokkeslæt (inklusive tidszoneforskydningen) ved starten af ​​den aktuelle transaktion.

Det svarer til den traditionelle Postgres-funktion now() .

Det ligner også current_timestamp funktion (når den kaldes uden et argument), bortset fra at den er navngivet for klart at afspejle, hvad den gør.

transaction_timestamp() Funktionen accepterer ikke nogen parametre, så du kan ikke angive dens præcision, hvorimod current_timestamp kan kaldes med eller uden en præcisionsparameter.

Også transaction_timestamp() er en ikke-SQL-standard funktion.

Syntaks

Syntaksen ser sådan ud:

transaction_timestamp()

Ingen argumenter er påkrævet eller accepteret.

Grundlæggende eksempel

Her er et grundlæggende eksempel at demonstrere.

SELECT transaction_timestamp();

Resultat:

2020-07-02 08:23:08.810484+10

Inden for en transaktion

Her er et eksempel, der viser, hvordan det fungerer inden for en transaktion.

BEGIN;
SELECT transaction_timestamp();
SELECT pg_sleep(5);
SELECT transaction_timestamp();
SELECT pg_sleep(5);
SELECT transaction_timestamp();
COMMIT;

Her er det fulde output i min terminal, når jeg bruger psql:

postgres=# BEGIN;
BEGIN
postgres=# SELECT transaction_timestamp();
     transaction_timestamp     
-------------------------------
 2020-07-02 08:27:04.229266+10
(1 row)


postgres=# SELECT pg_sleep(5);
 pg_sleep 
----------
 
(1 row)


postgres=# SELECT transaction_timestamp();
     transaction_timestamp     
-------------------------------
 2020-07-02 08:27:04.229266+10
(1 row)


postgres=# SELECT pg_sleep(5);
 pg_sleep 
----------
 
(1 row)


postgres=# SELECT transaction_timestamp();
     transaction_timestamp     
-------------------------------
 2020-07-02 08:27:04.229266+10
(1 row)


postgres=# COMMIT;
COMMIT

Alle tre tidsværdier er identiske, selvom pg_sleep() funktion blev brugt til at forsinke eksekveringen mellem hvert kald til transaction_timestamp() , som hver tilfældigvis var i sin egen SQL-sætning.

Så vi kan se, at den returnerede tid for hver erklæring er baseret på starttidspunktet for den aktuelle transaktion – ikke erklæringen. Det ændrer sig ikke, efterhånden som transaktionen skrider frem.

Dette gør det muligt for en enkelt transaktion at have en konsistent forestilling om det "aktuelle" tidspunkt, så flere ændringer inden for samme transaktion bærer det samme tidsstempel.

Flere opkald inden for et kontoudtog

Det ændrer sig heller ikke, efterhånden som udsagnet skrider frem.

\x
SELECT 
  transaction_timestamp(),
  pg_sleep(5),
  transaction_timestamp(),
  pg_sleep(5),
  transaction_timestamp();

Resultat (ved hjælp af lodret output):

transaction_timestamp | 2020-07-02 09:15:56.154175+10
pg_sleep              | 
transaction_timestamp | 2020-07-02 09:15:56.154175+10
pg_sleep              | 
transaction_timestamp | 2020-07-02 09:15:56.154175+10

Igen er alle tre tidsværdier identiske, selvom pg_sleep() funktion blev brugt til at forsinke eksekveringen mellem hvert kald til transaction_timestamp() .

Dette er i modsætning til statement_timestamp() , hvilket gør ændres med hver sætning, og også clock_timestamp() funktion, som ændres, selv når den skrider frem gennem hver sætning (hvis den kaldes flere gange i sætningen).