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 22628.1070293855@sss.pgh.pa.us
Whole thread Raw
In response to Re: clock_timestamp() and transaction_timestamp() function  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: clock_timestamp() and transaction_timestamp() function  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> This is a nonstarter,

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

Hm.  If you restricted the option to only those two values, it might be
safe as far as the stability argument goes, but it would be the sort
of thing where we'd have to be perpetually on our guard against someone
making the "obvious extension" and thereby subtly breaking things.

In general, I do not like options that subtly change the behavior of
long-established functions, anyway.  Seems like a great recipe for
breaking people's applications.  I'm okay with adding new functions as
per the already-agreed-to set of names (though like Peter I wish we
could think of something clearer than clock_timestamp()).  Rejiggering
the behavior of already-existing functions was not part of what had
been agreed to.

            regards, tom lane

pgsql-patches by date:

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