> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Bruce Momjian <pgman@candle.pha.pa.us> 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 parser/etc
> path. Otherwise
> >>> there's not a unique answer (consider statements issued inside SQL
> >>> functions for instance).
>
> >> Would it be reasonable to add one more timestamp that
> works the same
> >> inside and outside a function? In either case, can anyone
> think of a
> >> less-ambiguous name for timestamp_statement?
>
> > timestamp_client_statement? That highlights it is when the
> client sends
> > the statement.
>
> timestamp_command, maybe, would convey the right image.
>
> (I don't think we need yet a fourth flavor of this, nor do I
> see anything
> about it that "works differently inside and outside a function".)
Here's what I thought was going to happen:
psql> BEGIN; -- sets timestamp_transaction();
psql> SELECT func1(); -- sets timestamp_statement()
func1:
SELECT something; -- doesn't set timestamp_statement(), because it's in a function
call func2();
return;
psql> SELECT something; -- sets timestamp_statement() again
Maybe I just mis-understood and each statement that's issued will update timestamp_statement(). If that's the case I
thinkwe're fine (I can't really think of a use-case for timestamp_command() myself...).
OTOH, if the intention is to do what I outlined in the above timeline, I think we should also have timestamp_command(),
andchange timestamp_statement() so that it always indicates the timestamp at the start of the current statement.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com 512-569-9461