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