| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Wang Mike <itlist(at)msn(dot)com>, <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: clock_timestamp() and transaction_timestamp() function |
| Date: | 2003-12-01 10:48:40 |
| Message-ID: | Pine.LNX.4.44.0312011145140.22821-100000@peter.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Bruce Momjian writes:
> The goal was to give a unified API to the various time measurements:
>
> [clock|statement|transaction]_timestamp
It would be very useful if we had a parameter that controlled whether
current_timestamp maps to statement_timestamp or to transaction_timestamp.
There seems to be quite some disagreement over this issue, and this would
help resolve it and also prevent users from unnecessarily using
nonstandard functions in their application.
The name "clock_timestamp" seems kind of unfortunate. Where else would a
time stamp come from if not from the clock? Why is this functionality
needed anyway? It seems that it could only serve to produce
nondeterministic, unreproduceable results.
--
Peter Eisentraut peter_e(at)gmx(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-12-01 12:51:01 | Re: Make pg_dump dump conversions |
| Previous Message | Tom Lane | 2003-12-01 06:27:03 | Re: export FUNC_MAX_ARGS as a read-only GUC variable |