Re: clock_timestamp() and transaction_timestamp() function

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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