Re: clock_timestamp() and transaction_timestamp() function

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > It would be very useful if we had a parameter that controlled whether
> > current_timestamp maps to statement_timestamp or to transaction_timestamp.
>
> This is a nonstarter, as is the previous proposal to have a single
> function with an explicit parameter that selects the behavior. The
> reason is that any such function would have to be treated as completely
> non-optimizable. It's really important that current_timestamp be STABLE
> so that queries like
> where entrytimestamp >= current_timestamp - '10 minutes'
> can use an index. This means you can't have options that make it not
> be STABLE.

Oh, I forgot about that. Peter seems only to want statement_timestamp
and transaction_timestamp. Aren't those both stable if
statement_timestamp is set from exec_simple_query?

> > The name "clock_timestamp" seems kind of unfortunate.
>
> Agreed, it's not the best choice.
>
> > Why is this functionality needed anyway?
>
> Performance measurements within plpgsql functions, for example.
> I am unconvinced that anyone has really proven the need for
> statement_timestamp, but a cleaner replacement for timeofday()
> would be nice to have.

Yep, and if we say we need that then the GUC option doesn't work because
the certainly will not be stable.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073