On Tue, Oct 2, 2018 at 10:55:56AM +0200, Peter Eisentraut wrote: > On 28/09/2018 09:35, Peter Eisentraut wrote: > >> That's certainly a good argument. Note that if we implemented that the > >> transaction timestamp is advanced inside procedures, that would also > >> mean that the transaction timestamp as observed in pg_stat_activity > >> would move during VACUUM, for example. That might or might not be > >> desirable. > > > > Attached is a rough implementation. > > > > I'd be mildly in favor of doing this, but we have mentioned tradeoffs in > > this thread. > > So do we want to do this or not?
I thought some more about this. I think there are a few issues: 1 Utility: since you can't use CALL in a transaction block, our current code will always have transaction_timestamp() and statement_timestamp() as identical in a procedure. Having transaction_timestamp() advance on COMMIT gives users a new ability. 2 Surprise: What do people use transaction_timestamp() for and what behavior would be most expected? 3 Other databases: How do other database systems handle this, and the SQL standard? Based on 1 and 2, I suggest we change transaction_timestamp() to advance on COMMIT in procedure, and document this. I have no idea on #3. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +