Re: Additional current timestamp values

Kevin Grittner wrote:
> >>> On Mon, Mar 20, 2006 at 7:58 pm, in message
> <200603210158(dot)k2L1wMY01170(at)candle(dot)pha(dot)pa(dot)us>, Bruce Momjian
> <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> > Tom Lane wrote:
> >> But not once per statement --- in reality, you get a fairly
> arbitrary
> >> behavior that will advance in some cases and not others when
> dealing
> >> with a multi- statement querystring.
>
> >> "statement" isn't a great name for the units
> >> that we are actually processing. We're really wanting to do these
> >> things once per client command, or maybe per client query would be a
> >> better name.
> >
> > Right.
>
> What about "query string"? If you want to include the term "client", I
> would find "client query string" less confusing than "client command" or
> "client query". If it's not always in the form of a string, maybe
> "client xxx batch", where xxx could be statement, request, command, or
> query.

We could use something like query_arrived_timestamp or something like
that, but it kind of confuses the distinction between it and
transaction_timestamp(), and for 99% of users, they don't even realize
you can send multiple statements in a single query. I am thinking we
call it statement_timestamp (like statement_timeout) and just document
its behavior. No one has problems with statement_timeout(), and that
has the exact same behavior as statement_timestamp() will have.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +