sql >> Databasteknik >  >> RDS >> PostgreSQL

Hur transaction_timestamp() fungerar i PostgreSQL

I PostgreSQL, transaction_timestamp() funktionen returnerar aktuellt datum och tid (inklusive tidszonsförskjutningen), i början av den aktuella transaktionen.

Det är motsvarigheten till den traditionella Postgres-funktionen now() .

Det liknar också current_timestamp funktion (när den anropas utan argument), förutom att den är namngiven för att tydligt återspegla vad den gör.

transaction_timestamp() Funktionen accepterar inte några parametrar, så du kan inte specificera dess precision, medan current_timestamp kan anropas med eller utan en precisionsparameter.

Även transaction_timestamp() är en icke-SQL-standardfunktion.

Syntax

Syntaxen ser ut så här:

transaction_timestamp()

Inga argument krävs eller accepteras.

Grundläggande exempel

Här är ett grundläggande exempel att visa.

SELECT transaction_timestamp();

Resultat:

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

Inom en transaktion

Här är ett exempel för att visa hur det fungerar inom en transaktion.

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

Här är hela resultatet i min terminal när jag använder 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

Alla tre tidsvärdena är identiska, även om pg_sleep() funktion användes för att fördröja exekvering mellan varje anrop till transaction_timestamp() , som var och en råkade vara i sin egen SQL-sats.

Så vi kan se att tiden som returneras för varje uttalande baseras på starttiden för den aktuella transaktionen – inte uttalandet. Det ändras inte när transaktionen fortskrider.

Detta tillåter en enskild transaktion att ha en konsekvent uppfattning om den "aktuella" tiden, så att flera ändringar inom samma transaktion har samma tidsstämpel.

Flera samtal inom ett kontoutdrag

Det ändras inte heller när uttalandet fortskrider.

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

Resultat (med vertikal utdata):

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

Återigen, alla tre tidsvärdena är identiska, även om pg_sleep() funktion användes för att fördröja exekvering mellan varje anrop till transaction_timestamp() .

Detta är i motsats till statement_timestamp() , vilket gör ändras med varje sats, och även clock_timestamp() funktion, som ändras även när den fortskrider genom varje sats (om den anropas flera gånger i satsen).


  1. körtidsfel:java.lang.ClassNotFoundException:com.mysql.jdbc.Driver

  2. Star Schema vs Snowflake Schema

  3. Använder Dapper med Oracle lagrade procedurer som returnerar markörer

  4. Hur skickar man godtyckliga parametrar till Oracle trigger?