> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Bruce Momjian writes:
> > Jim C. Nasby wrote:
> >> On Sat, Aug 13, 2005 at 06:24:01PM -0400, Tom Lane wrote:
> >>> IIRC, what we actually intended that to mean is the time
> of receipt of
> >>> the current interactive command --- that is, it gets set i
On Sat, Aug 13, 2005 at 06:24:01PM -0400, Tom Lane wrote:
> Brendan Jurd <[EMAIL PROTECTED]> writes:
> > Regarding the statement_timestamp() ... if the entire query path is
> > parser -> rewriter -> planner/optimiser -> executor, what point in
> > that path would be considered the true start of the
Bruce Momjian writes:
> Jim C. Nasby wrote:
>> On Sat, Aug 13, 2005 at 06:24:01PM -0400, Tom Lane wrote:
>>> IIRC, what we actually intended that to mean is the time of receipt of
>>> the current interactive command --- that is, it gets set in the
>>> postgres.c outer loop, not anywhere in the par
Jim C. Nasby wrote:
> On Sat, Aug 13, 2005 at 06:24:01PM -0400, Tom Lane wrote:
> > Brendan Jurd <[EMAIL PROTECTED]> writes:
> > > Regarding the statement_timestamp() ... if the entire query path is
> > > parser -> rewriter -> planner/optimiser -> executor, what point in
> > > that path would be co
Brendan Jurd <[EMAIL PROTECTED]> writes:
> Regarding the statement_timestamp() ... if the entire query path is
> parser -> rewriter -> planner/optimiser -> executor, what point in
> that path would be considered the true start of the "statement"?
IIRC, what we actually intended that to mean is the
On Sun, Aug 14, 2005 at 05:51:16AM +1000, Brendan Jurd wrote:
> Regarding the statement_timestamp() ... if the entire query path is
> parser -> rewriter -> planner/optimiser -> executor, what point in
> that path would be considered the true start of the "statement"? I
> would assume that it's rig
On 8/14/05, Bruce Momjian wrote:
> Brendan Jurd wrote:
> > > We already have a TODO for this:
> > >
> > > * Add transaction_timestamp(), statement_timestamp(),
> > > clock_timestamp()
> > > functionality
> >
> > I like the idea of having a function for statement start time. I
>
> We already have a TODO for this:
>
> * Add transaction_timestamp(), statement_timestamp(),
> clock_timestamp()
> functionality
I like the idea of having a function for statement start time. I
think I'll incorporate it into my patch.
The suggested naming convention in the TO
Brendan Jurd wrote:
> Hi all,
>
> I propose to add an internal function gettime() that transparently
> returns the current system time, as a timestamptz with maximum
> precision.
>
> Calling gettime() would be a more elegant approach than calling
> timeofday() and converting it to a timestamp, an
Hi all,
I propose to add an internal function gettime() that transparently
returns the current system time, as a timestamptz with maximum
precision.
Calling gettime() would be a more elegant approach than calling
timeofday() and converting it to a timestamp, and avoids some of the
potential probl
10 matches
Mail list logo
