From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Andrew Sullivan" <andrew(at)libertyrms(dot)info>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [SQL] [GENERAL] CURRENT_TIMESTAMP |
Date: | 2002-10-04 13:54:42 |
Message-ID: | 20186.1033739682@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
> Note also, that a typical SELECT only session would not advance
> CURRENT_TIMESTAMP at all in the typical "autocommit off" mode that
> the Spec is all about.
True, but the spec also says to default to serializable transaction
mode. So in a single-transaction session like you are picturing,
the successive SELECTs would all see a frozen snapshot of the database.
Freezing CURRENT_TIMESTAMP goes right along with that, and in fact makes
a lot of sense, because it tells you exactly what time your snapshot
of the database state was taken.
This line of thought opens another can of worms: should the behavior
of CURRENT_TIMESTAMP depend on serializable vs. read-committed mode?
Maybe SetQuerySnapshot is the routine that ought to capture the
"statement-start-time" timestamp value. We could define
CURRENT_TIMESTAMP as the time of the active database snapshot.
Or at least offer a fourth parameter to that parameterized now() to
return this time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2002-10-04 14:22:00 | Re: Threaded Sorting |
Previous Message | Tom Lane | 2002-10-04 13:45:57 | Re: Threaded Sorting |