There is also another blocker - our timestamp resolution is 1
microsecond and we are dangerously close to speeds where one could
update a row twice in the same microsecond .
I have been thinking about this, and what is needed is
1. a nanosecond-resolution "abstime" type - not absolutely necessary
W dniu sob, 25.02.2023 o godzinie 03∶11 +0100, użytkownik Vik Fearing
napisał:
> On 2/24/23 22:06, Corey Huinker wrote:
>
> The main design blocker for me is how to handle dump/restore. The
> standard does not bother thinking about that.
That would be a little difficult. Most probably you would
On 2/24/23 22:06, Corey Huinker wrote:
On Thu, Feb 23, 2023 at 6:04 AM 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
sys
On Thu, Feb 23, 2023 at 6:04 AM wrote:
> Hey,
>
> It depnends on scenario, but there is many use cases that hack data
> change from somebody with admin privileges could be disaster.
> That is the place where data history could come with help. Some basic
> solution would be trigger which writes p
