Re: tracking commit timestamps - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: tracking commit timestamps
Date
Msg-id CAHyXU0xg7vDAEo3RR0-4D8W6mGCwV-fpgvtrQcsKJvi5rs0TfA@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Mon, Nov 3, 2014 at 3:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 11/1/14 8:04 AM, Petr Jelinek wrote:
>> On second thought, maybe those should be pg_get_transaction_committs,
>> pg_get_transaction_committs_data, etc.
>
> Please don't name anything "committs".  That looks like a misspelling of
> something.
>
> There is nothing wrong with
>
> pg_get_transaction_commit_timestamp()
>
> If you want to reduce the length, lose the "get".

+1: all non void returning functions 'get' something.

>> For me the commit time thing feels problematic in the way I perceive it
>> - I see commit time as a point in time, where I see commit timestamp (or
>> committs for short) as something that can recorded. So I would prefer to
>> stick with commit timestamp/committs.
>
> In PostgreSQL, it is pretty clearly established that time is hours,
> minutes, seconds, and timestamp is years, months, days, hours, minutes,
> seconds.  So unless this feature only records the hour, minute, and
> second of a commit, it should be "timestamp".

Elsewhere, for example, we have: "pg_last_xact_replay_timestamp()".
So, in keeping with that, maybe,

pg_xact_commit_timestamp(xid)

merlin



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Let's drop two obsolete features which are bear-traps for novices
Next
From: Álvaro Hernández Tortosa
Date:
Subject: Re: Repeatable read and serializable transactions see data committed after tx start