Patch applied, and catalog version updated.
---
Bruce Momjian wrote:
>
> Here is an updated patch. I broke out the statement_timestamp and
> statement_timeout handling into separate functions, initialize_command()
> and fi
Here is an updated patch. I broke out the statement_timestamp and
statement_timeout handling into separate functions, initialize_command()
and finalize_command(), which call the xact start/stop internally.
This clears up the API because now start/stop xact can be called
independent of the statem
I am not happy with my patch and am going to try a more comprehensive
restructuring --- will post later.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> The patch as given s
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The patch as given strikes me as pretty broken --- it does not advance
> >> statement_timestamp when I would expect (AFAICS it only sets it during
> >> transaction start).
>
> > Uh, it does advance:
>
> But not once per statement -
Kevin Grittner wrote:
> >>> On Mon, Mar 20, 2006 at 7:58 pm, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> 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
> >>
Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> >>> "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.
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
>>> "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"?
>>> On Mon, Mar 20, 2006 at 7:58 pm, in message
<[EMAIL PROTECTED]>, Bruce Momjian
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.
>
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The patch as given strikes me as pretty broken --- it does not advance
> >> statement_timestamp when I would expect (AFAICS it only sets it during
> >> transaction start).
>
> > Uh, it does advance:
>
> But not once per statement -
Bruce Momjian writes:
> Tom Lane wrote:
>> The patch as given strikes me as pretty broken --- it does not advance
>> statement_timestamp when I would expect (AFAICS it only sets it during
>> transaction start).
> Uh, it does advance:
But not once per statement --- in reality, you get a fairly ar
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> One trick is that these should be the same:
> >> test=> SELECT statement_timestamp(), transaction_timestamp();
>
> > Should they be?
>
> ISTM that the most useful definition of "statement_timestamp" is really
Neil Conway <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> One trick is that these should be the same:
>> test=> SELECT statement_timestamp(), transaction_timestamp();
> Should they be?
ISTM that the most useful definition of "statement_timestamp" is really
"time of arrival of the latest i
Neil Conway wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> The most common complaint that I recall is that current_timestamp
> >> returns the transaction timestamp rather than the statement timestamp,
> >> which is what many expect. How does your patch address that?
> >
> > No,
Neil Conway wrote:
> Bruce Momjian wrote:
> > CURRENT_TIMESTAMP might not be the
> > transaction start time on other database systems.
> > For this reason, and for completeness,
> > transaction_timestamp is provided.
>
> Well, transaction_timestamp() is even more unlikely to be the
Bruce Momjian wrote:
Peter Eisentraut wrote:
The most common complaint that I recall is that current_timestamp
returns the transaction timestamp rather than the statement timestamp,
which is what many expect. How does your patch address that?
No, we believe the standard requires it.
My cop
Bruce Momjian wrote:
CURRENT_TIMESTAMP might not be the
transaction start time on other database systems.
For this reason, and for completeness,
transaction_timestamp is provided.
Well, transaction_timestamp() is even more unlikely to be the
transaction start time on other data
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Rather than applying the above patch, I have implemented this TODO
> > with the attached patch:
> >
> > * Add transaction_timestamp(), statement_timestamp(),
> > clock_timestamp() functionality
>
> The most common complaint that I recall is th
Bruce Momjian wrote:
> Rather than applying the above patch, I have implemented this TODO
> with the attached patch:
>
> * Add transaction_timestamp(), statement_timestamp(),
> clock_timestamp() functionality
The most common complaint that I recall is that current_timestamp
returns the tran
I hBrendan Jurd wrote:
> On 8/7/05, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I propose to add an internal function gettime() that transparently
> > returns the current system time, as a timestamptz with maximum
> > precision.
Rather than applying the above patch, I have impleme
19 matches
Mail list logo
