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
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 |