On 25/10/2019 11:56, Surafel Temesgen wrote: > > > On Thu, Oct 24, 2019 at 6:49 PM Vik Fearing > <vik.fear...@2ndquadrant.com <mailto:vik.fear...@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.fear...@2ndquadrant.com > <mailto:vik.fear...@2ndquadrant.com> > <mailto:vik.fear...@2ndquadrant.com > <mailto:vik.fear...@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
How? The primary/unique keys must always be unique at every point in time.
