>> Yes, user-visible. They give additional current timestamp information.
>> transaction_timestamp() is the same as current_timestamp,
>> clock_timestamp is the same as gettimeofday(), and statement_timestamp
>> is a new one that shows statement start time.
>
> And what would be the point of that
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> This is a nonstarter, as is the previous proposal to have a single
>> function with an explicit parameter that selects the behavior. The
>> reason is that any such function would have to be treated as completely
>> non-optimizable.
Tom Lane wrote:
> 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
Tom Lane writes:
> This is a nonstarter, as is the previous proposal to have a single
> function with an explicit parameter that selects the behavior. The
> reason is that any such function would have to be treated as completely
> non-optimizable.
Why? We would just need to ensure that the mode
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> This is a nonstarter, as is the previous proposal to have a single
> >> function with an explicit parameter that selects the behavior. The
> >> reason is that any such function would have to be treated as comp
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 o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It would be very useful if we had a parameter that controlled whether
> current_timestamp maps to statement_timestamp or to transaction_timestamp.
This is a nonstarter, as is the previous proposal to have a single
function with an explicit parameter t
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It would be very useful if we had a parameter that controlled whether
> > current_timestamp maps to statement_timestamp or to transaction_timestamp.
>
> This is a nonstarter, as is the previous proposal to have a single
> function
Peter Eisentraut wrote:
> 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
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 see
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Yes, user-visible. They give additional current timestamp information.
> > transaction_timestamp() is the same as current_timestamp,
> > clock_timestamp is the same as gettimeofday(), and statement_timestamp
> > is a new one that shows stateme
Bruce Momjian writes:
> Yes, user-visible. They give additional current timestamp information.
> transaction_timestamp() is the same as current_timestamp,
> clock_timestamp is the same as gettimeofday(), and statement_timestamp
> is a new one that shows statement start time.
And what would be th
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > We have started 7.5 development so we can now work with you to complete
> > this item. Your question was what does statement_timestamp() show.
> > That has been discussed and it is a little tricky. The idea is that is
> > should be start of a
Bruce Momjian writes:
> We have started 7.5 development so we can now work with you to complete
> this item. Your question was what does statement_timestamp() show.
> That has been discussed and it is a little tricky. The idea is that is
> should be start of a single statement that arrives from
We have started 7.5 development so we can now work with you to complete
this item. Your question was what does statement_timestamp() show.
That has been discussed and it is a little tricky. The idea is that is
should be start of a single statement that arrives from the user or is
requestd by a
Wang Mike wrote:
> add clock_timestamp() and transaction_timestamp() function
>
> see TODO list get more
>
> -
>
> diff -u -r ../cvs/pgsql/src/backend/utils/adt/timestamp.c
> ../pgsql/src/backend/utils/adt/timestamp.c
> --- ../cvs/
add clock_timestamp() and transaction_timestamp() function
see TODO list get more
-
diff -u -r ../cvs/pgsql/src/backend/utils/adt/timestamp.c
../pgsql/src/backend/utils/adt/timestamp.c
--- ../cvs/pgsql/src/backend/utils/adt/timesta
17 matches
Mail list logo
