Kevin Grittner wrote: > >>> On Mon, Mar 20, 2006 at 7:58 pm, in message > <[EMAIL PROTECTED]>, Bruce Momjian > <pgman@candle.pha.pa.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. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
