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
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
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
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
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 previous version of record
to some other table.
