From: Bruce Momjian <bruce@momjian.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: transction_timestamp() inside of procedures
Date: Fri, 21 Sep 2018 18:35:02 -0400
Message-ID: <20180921223502.GA18319@momjian.us> (raw)
In-Reply-To: <20180921102822.GA22699@momjian.us>
References: <20180920234040.GC29981@momjian.us>
<20180921045536.GJ1338@paquier.xyz>
<20180921051206.bzfiew4nthmunpbj@alap3.anarazel.de>
<20180921053425.GM1338@paquier.xyz>
<20180921102822.GA22699@momjian.us>
On Fri, Sep 21, 2018 at 06:28:22AM -0400, Bruce Momjian wrote:
> On Fri, Sep 21, 2018 at 02:34:25PM +0900, Michael Paquier wrote:
> > On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote:
> > > Isn't the point that transaction_timestamp() does *not* currently change
> > > its value, even though the transaction (although not the outermost
> > > statement) has finished?
> >
> > Ouch, yes. I see the point now. Indeed that's strange to not have a
> > new transaction timestamp after commit within the DO block..
>
> So, this puts us in an odd position. Right now everyone knows that
> statement_timestamp() is only changed by the outer statement, i.e., a
> SELECT in a function doesn't change statement_timestamp(). So, there
> is an argument that transaction_timestamp() should do the same and not
> change in a function --- in fact, if it does change, it would mean that
> transaction_timestamp() changes in a function, but statement_timestamp()
> doesn't --- that seems very odd. It would mean that new statements in a
> function don't change statement_timestamp(), but new transctions in a
> function do --- again, very odd.
Sorry I was unclear about this. It is only the third loop that proves
it is not advancing:
NOTICE: clock 2018-09-21 18:01:00.63704-04
NOTICE: statement 2018-09-21 18:01:00.636509-04
NOTICE: transaction 2018-09-21 18:01:00.636509-04
NOTICE: clock 2018-09-21 18:01:02.640033-04
NOTICE: statement 2018-09-21 18:01:00.636509-04
NOTICE: transaction 2018-09-21 18:01:00.636509-04
NOTICE: clock 2018-09-21 18:01:04.642266-04
NOTICE: statement 2018-09-21 18:01:00.636509-04
--> NOTICE: transaction 2018-09-21 18:01:00.636509-04
Keep in mind that transaction_timestamp() is CURRENT_TIMESTAMP.
I have always thought of clock/statement/transation as decreasing levels
of time precision, and it might be odd to change that. I don't think we
want to change the behavior of statement_timestamp() in procedures, so
that kind of requires us not to change transaction_timestamp() inside of
procedures.
However, no change in behavior causes the problem that if you have a
transaction block using transaction_timestamp() or CURRENT_TIMESTAMP,
and you move it into a procedure, the behavior of those functions will
change, but this was always true of moving statement_timestamp() into a
function, and I have never heard a complaint about that.
Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
procedures? Do we need another function that does advance on procedure
commit?
--
Bruce Momjian <bruce@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 +
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, michael@paquier.xyz, andres@anarazel.de
Subject: Re: transction_timestamp() inside of procedures
In-Reply-To: <20180921223502.GA18319@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox