Re: [GENERAL] CURRENT_TIMESTAMP

Tom,

> If we leave now() alone then there's no need to create another
> non-spec-compliant syntax like 'transaction_timestamp', either.
> (I really don't want to see us do that, because without parens
> it would mean making a new, not-in-the-spec fully-reserved word.)

So, if I've got this straight:

-- current_timestamp will return the timestamp for the beginning of the
SQL statement.

-- now() will return the timestamp for the beginning of the
transaction.

-- timeofday() will return the timestamp of the exact time the function
is called.

... thus changing only current_timestamp.

This looks fine to me, as a search-and-replace on current_timestamp is
easy. However, we need to do a better job of warning people about the
change than we did with interval() to "interval"().

Actually, can I make the proposal that *any* change that breaks
backward compatibility be mentioned in both the new version
announcement and on the download page? This would prevent a lot of
grief. If I'm kept informed of these changes, I'll be happy to write
up a user-friendly announcement/instructions on how to cope with the
change.

> BTW, as long as we are dorking with the current-time family, does
> anyone want to vote for changing timeofday() to return a timestamptz
> instead of a text string? There's no good argument except slavish
> backward compatibility for having it return text, and we seem to be
> quite willing to ignore backwards compatibility in this thread ...

No, I don't see any reason to do this. It's not like timeofday() is a
particularly logical name, anyway. Why not introduce a new function,
rightnow(), that returns timestamptz?

Better yet, how about we introduce a parameter to now()? Example:

now() or now('transaction') returns the transaction timestamp.
now('statement') returns the statement timestamp
now('immediate') returns the timestamp at the exact time the function
is called.

This would seem to me much more consistent than having 3 different
time-calls, whose names have nothing to do with the difference between
them. And it has the advantage of not breaking backward compatibility.

We could introduce the new version of now() in 7.4, encourage everyone
to use it instead of other timestamp calls, and then in 7.5 change the
behavior of current_timestamp for SQL92 compliance.

-Josh Berkus