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

Re: Additional current timestamp values

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04-23 03:04:15
Message-ID: 200604230304.k3N34Ft16550@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-04-23 03:33:54
Subject: Re: Additional current timestamp values
Previous:From: Tatsuo IshiiDate: 2006-04-23 01:13:31
Subject: Re: obtaining row locking information

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-04-23 03:33:54
Subject: Re: Additional current timestamp values
Previous:From: davegDate: 2006-04-22 21:20:32
Subject: Re: [HACKERS] Automatically setting work_mem

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