Re: WIP: System Versioned Temporal Table - Mailing list pgsql-hackers

From Surafel Temesgen
Subject Re: WIP: System Versioned Temporal Table
Date
Msg-id CALAY4q8xpuU7Qz7qy+5F8bh=GPAwR-pyscorAzTpyTQGyZbqtQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: System Versioned Temporal Table  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Responses Re: WIP: System Versioned Temporal Table  (Vik Fearing <vik.fearing@2ndquadrant.com>)
List pgsql-hackers


On Thu, Oct 24, 2019 at 6:49 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote:
On 24/10/2019 16:54, Surafel Temesgen wrote:
>
> hi Vik,
> On Wed, Oct 23, 2019 at 9:02 PM Vik Fearing
> <vik.fearing@2ndquadrant.com <mailto:vik.fearing@2ndquadrant.com>> wrote:
>  
>
>
>     If we're going to be implicitly adding stuff to the PK, we also
>     need to
>     add that stuff to the other unique constraints, no?  And I think it
>     would be better to add both the start and the end column to these
>     keys. 
>     Most of the temporal queries will be accessing both.
>
>  
> yes it have to be added to other constraint too but adding both system
> time 
> to PK will violate constraint because it allow multiple data in
> current data


I don't understand what you mean by this.



The primary purpose of adding row end time to primary key is to allow duplicate value to be inserted into a table with keeping constraint in current data but it can be duplicated in history data. Adding row start time column to primary key will eliminate this uniqueness for current data which is not correct  

regards
Surafel

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: define bool in pgtypeslib_extern.h
Next
From: Amit Kapila
Date:
Subject: Re: Ordering of header file inclusion