Re: FW: bitemporal functionality for PostgreSQL

From: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FW: bitemporal functionality for PostgreSQL
Date: 2008-02-01 16:15:26
Message-ID: 0EC548BA-217F-45F3-A85F-3D8ED96EE0CF@themactionfaction.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Feb 1, 2008, at 10:42 AM, Luke Porter wrote:

> All
>
> Is there an interest in developing bitemporal functionality in
> PostgreSQL
>
> Regards
>
> Luke

I can only speak for myself, but- definitely! Based on the googling I
did on "bitemporal database", I kind of do this already with
PostgreSQL. Some of my tables are insert-only and each row includes a
committed time timestamp. That way, I don't need a separate audit log
table, and "fixing" someone's mistake is as simple as copying old
rows. The downside to this is that I need a view to represent the
current "truth" and calculating the truth is more expensive than a
simple table would be.

Can you explain in more detail or provide references to how
PostgreSQL could potentially handle temporal data better?

One idea I had would be to blow the transaction ID up to 128 bits (no
more wrapping!) and have it represent the nanoseconds since the epoch.

Cheers,
M

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-01 16:16:20 Re: <IDLE> and waiting
Previous Message Andrew Gilligan 2008-02-01 16:14:45 BUG #3921: CREATE TABLE / INCLUDING INDEXES fails with permission denied