Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Sep 28, 2002 at 11:51:32PM -0400, Bruce Momjian wrote:
>> Yes, it will split now() and CURRENT_TIMESTAMP. I personally would be
>> happy with STATEMENT_TIMESTAMP, but because the standard requires it we
>> may just have to fix CURRENT_TIMESTAMP.
> Well, my vote would be for STATEMENT_TIMESTAMP.
One problem with inventing STATEMENT_TIMESTAMP is that (if spelled that
way, without parens) it would have to become a fully-reserved keyword,
thus possibly breaking some applications that use that name now.
But the real point, I think, is that the folks pushing for this think
that the standard requires CURRENT_TIMESTAMP to be statement timestamp.
Inventing some other keyword isn't going to satisfy them.
I don't personally find the "it's required by the spec" argument
compelling, because the spec specifically says that the exact behavior
is implementation-dependent --- so anyone who assumes CURRENT_TIMESTAMP
will behave as start-of-statement timestamp is going to have portability
problems anyway. Oracle didn't seem to find the argument compelling
either; at last report they have no statement-timestamp function.
I'd be happier with the whole thing if anyone had exhibited a convincing
use-case for statement timestamp. So far I've not seen any actual
examples of situations that are not better served by either transaction
timestamp or true current time. And the spec is perfectly clear that
CURRENT_TIMESTAMP does not mean true current time...
regards, tom lane
