From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, marekmosiewicz(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Disable vacuuming to provide data history |
Date: | 2023-02-25 02:11:03 |
Message-ID: | ad2cd43b-0e98-1683-99c8-e9d54bacdb26@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/24/23 22:06, Corey Huinker wrote:
> On Thu, Feb 23, 2023 at 6:04 AM <marekmosiewicz(at)gmail(dot)com> wrote:
>
> [1] some implementations don't use null, they use an end-timestamp set to
> a date implausibly far in the future ( 3999-12-31 for example ),
The specification is, "At any point in time, all rows that have their
system-time period end column set to the highest value supported by the
data type of that column are known as current system rows; all other
rows are known as historical system rows."
I would like to see us use 'infinity' for this.
The main design blocker for me is how to handle dump/restore. The
standard does not bother thinking about that.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wolak | 2023-02-25 03:56:16 | Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql) |
Previous Message | Jeff Davis | 2023-02-24 23:54:15 | Re: Move defaults toward ICU in 16? |