Re: WIP: System Versioned Temporal Table

On 25/10/2019 11:56, Surafel Temesgen wrote:
>
>
> On Thu, Oct 24, 2019 at 6:49 PM Vik Fearing
> <vik(dot)fearing(at)2ndquadrant(dot)com <mailto:vik(dot)fearing(at)2ndquadrant(dot)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(dot)fearing(at)2ndquadrant(dot)com
> <mailto:vik(dot)fearing(at)2ndquadrant(dot)com>
> <mailto:vik(dot)fearing(at)2ndquadrant(dot)com
> <mailto:vik(dot)fearing(at)2ndquadrant(dot)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  

How?  The primary/unique keys must always be unique at every point in time.