Re: clock_timestamp() and transaction_timestamp() function - Mailing list pgsql-patches

From Tom Lane
Subject Re: clock_timestamp() and transaction_timestamp() function
Date
Msg-id 22492.1070292844@sss.pgh.pa.us
Whole thread Raw
In response to Re: clock_timestamp() and transaction_timestamp() function  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: clock_timestamp() and transaction_timestamp() function  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-patches
Peter Eisentraut <peter_e@gmx.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.

> 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.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: clock_timestamp() and transaction_timestamp() function
Next
From: Tom Lane
Date:
Subject: Re: clock_timestamp() and transaction_timestamp() function