Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster