From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        Andres Freund <andres@anarazel.de>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: transction_timestamp() inside of procedures
In-reply-to: <20180926125207.GA10161@momjian.us>
References: <20180920234040.GC29981@momjian.us>
 <20180921045536.GJ1338@paquier.xyz>
 <20180921051206.bzfiew4nthmunpbj@alap3.anarazel.de>
 <20180921053425.GM1338@paquier.xyz> <20180921102822.GA22699@momjian.us>
 <20180921223502.GA18319@momjian.us>
 <d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com>
 <20180926125207.GA10161@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Wed, 26 Sep 2018 08:52:07 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23173.1537970823.1@sss.pgh.pa.us>
Date: Wed, 26 Sep 2018 10:07:03 -0400
Message-ID: <23174.1537970823@sss.pgh.pa.us>
Precedence: bulk

Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote:
>> We could certainly address this by adding three or four or five new
>> timestamps that cover all these varieties.  But perhaps it's worth
>> asking what these timestamps are useful for and which ones we really need.

> Frankly, we might be fine with just documenting it and see if anyone
> complains.

I'm not for adding a bunch of new action-start timestamps without very
clear use-cases for them, because each one we add means more gettimeday()
overhead that might or might not ever be useful.

I agree that it would be surprising for transaction timestamp to be newer
than statement timestamp.  So for now at least, I'd be satisfied with
documenting the behavior.

			regards, tom lane