Re: Additional current timestamp values

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>,<pgsql-patches(at)postgresql(dot)org>, "Neil Conway" <neilc(at)samurai(dot)com>
Subject: Re: Additional current timestamp values
Date: 2006-03-30 23:50:02
Message-ID: 442C1A4A.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

>>> 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.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2006-03-31 02:01:18 Re: autovacuum: could not access status of transaction
Previous Message Andrew Dunstan 2006-03-30 22:17:38 Re: Tru64/Alpha problems

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-03-31 04:07:22 Re: Additional current timestamp values
Previous Message Tom Lane 2006-03-30 16:31:17 Re: Patch proposal for log_duration