> From: Tom Lane [mailto:[EMAIL PROTECTED] > 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 think we'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(), and change timestamp_statement() so that it always indicates the timestamp at the start of the current statement. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
