Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
