Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match