Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group