From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: josh@agliodbs.com, Martijn van Oosterhout <kleptog@svana.org>
Cc: Manfred Koizar <mkoi-pg@aon.at>
Cc: Roland Roberts <roland@astrofoto.org>
Cc: pgsql-sql@postgresql.org
Cc: pgsql-general@postgresql.org
Subject: Re: [SQL] CURRENT_TIMESTAMP
Date: Mon, 30 Sep 2002 00:36:34 -0400
Message-ID: <14905.1033360594@sss.pgh.pa.us> (raw)
In-Reply-To: <200209292038.g8TKcbR15198@candle.pha.pa.us>
References: <200209292038.g8TKcbR15198@candle.pha.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Now, they are _not_ saying the statement can't have the same time as
> other statements in the transaction, but I don't see why they would
> explicitly have to state that.
Allow me to turn that around: given that they clearly do NOT state that,
how can you argue that "the spec requires it"? AFAICS the spec does not
require it. In most places they are considerably more explicit than
this about stating what is required.
> We already have two other databases who are doing this timing at
> statement level.
The behavior of CURRENT_TIMESTAMP is clearly stated by the spec to be
implementation-dependent. We are under no compulsion to follow any
specific other implementation. If we were going to follow some other
lead, I'd look to Oracle first...
> If we change CURRENT_TIMESTAMP to statement time, I don't think we need
> now(""), but if we don't change it, I think we do --- somehow we should
> allow users to access statement time.
I have no problem with providing a function to access statement time,
and now('something') seems a reasonable spelling of that function.
But I think the argument that we should change our historical behavior
of CURRENT_TIMESTAMP is very weak.
One reason why I have a problem with the notion that the spec requires
CURRENT_TIMESTAMP to mean "time of arrival of the current interactive
command" (which is the only specific definition I've seen mentioned
here) is that the spec does not truly have a notion of interactive
command to begin with. AFAICT the spec's model of command execution
is ecpg-like: you have commands embedded in a calling language with
all sorts of opportunities for pre-planning, pre-execution, etc.
The notion of command arrival time is extremely fuzzy in this model.
It could very well be the time you compiled the ecpg application, or
the time you started the application running.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgman@candle.pha.pa.us, kleptog@svana.org, mkoi-pg@aon.at, roland@astrofoto.org, pgsql-general@postgresql.org
Subject: Re: [SQL] CURRENT_TIMESTAMP
In-Reply-To: <14905.1033360594@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox