Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iP748-00063Z-U4 for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2019 15:36:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iP747-0005VH-JE for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2019 15:36:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iP747-0005V3-6Y for pgsql-hackers@lists.postgresql.org; Mon, 28 Oct 2019 15:36:19 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iP744-0003UJ-PF for pgsql-hackers@postgresql.org; Mon, 28 Oct 2019 15:36:18 +0000 Received: by mail-wr1-x435.google.com with SMTP id e11so10386949wrv.4 for ; Mon, 28 Oct 2019 08:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QViTDnfzvlLEyU38bt7U52SAWTN/7Mxrm/hJkEtxzgk=; b=jolozSGWByQZ8H8v2LX/Q/ZxZBzOSnbsLvGY7IgMKxmBYWMdYZVgVG2ysMVukQLz6n 9E/xiKmkWJU12VvumEghccZ4fpoHx2rGpT1X37RY4cZ/c+HGxdbu20j6zKnRhs973Mdu 2XAxy15OkARCrdPJuCp5u9g6HParVvWWATUVgtF2uo/ldfCuhufev9/XAxIREdJAIhLr O7bHgrX+Hw9dEnAOP8vgc01EkTYxD4TjH0YZMUtgsMfoNz5RjeN/rP5qHMKxZdXkHSVc nsYKG2QxVyk3VvxYgEeZWCzZ5+hvC7CQpgED8oS/cJzpvhpAwntP2PzK0QJtH71go4KK qZDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QViTDnfzvlLEyU38bt7U52SAWTN/7Mxrm/hJkEtxzgk=; b=EVpiLMxkn5St5qnOGQLY6ShNnuLc80yoPgdw3r6i6hCTrlnJYO3XPUnnkc/3CaJRzw OjE5h/qIkvjGTAjCBp1w+r3SloIHrtmupfxW9ra2bsCmdNohV8j9CzezwZmav/q56hPE L6UsxahzHDnHJMl2yw2lyZZiuymKSf/7f20XyZM0e8GBUNQnrVbzq8p2YZ2SKayDEMpW zJyiafxnJe/S9VRsYJIDcJM0B307FLCcwHnkRxpob47izWBLpNlQKZwJRd9pA7JOcLbR KaZTHysIsUtdM34h5xNP26EjpNKhnlX7Gh3fACWFk2ZWXxqSac9BRmR4D1t5FFAtnJ7a Vmbg== X-Gm-Message-State: APjAAAV1RlO00uBNp8dYS3jkSOD58SSvWN25mtaxH8wVRhVxa1RT3Y8i wUqKKtuKQT+4yYqArzQ/2xmCkhMSeuXxBHEXVLmUEExZoWME33UBN2dDgPHyRUaaEw3roQ+zYkE S/wMq5ERvDF266CO1nkip4vaC7QfxNv68nSbAgVJIZyce8z2S2jCD30DJycJbbbKk3IR3/Z2z/o fuw4Ji1q1fbXAy X-Google-Smtp-Source: APXvYqxcjOHOqAumcDG4xTS+Jrm6MPWGZpsA8n+RWG34+D0ymp74CI3N6/IlxFoC8rZBKeN7tvQqqw== X-Received: by 2002:adf:f04e:: with SMTP id t14mr16027722wro.106.1572276974191; Mon, 28 Oct 2019 08:36:14 -0700 (PDT) Received: from [10.8.8.10] ([185.94.189.190]) by smtp.gmail.com with ESMTPSA id p17sm13435331wrn.4.2019.10.28.08.36.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 08:36:13 -0700 (PDT) Subject: Re: WIP: System Versioned Temporal Table To: Surafel Temesgen Cc: PostgreSQL Hackers References: <3de42e96-45c3-faaa-af20-30f127724601@2ndquadrant.com> <55cf779b-a347-8c21-9a82-ad2030f95d0b@2ndquadrant.com> From: Vik Fearing Message-ID: Date: Mon, 28 Oct 2019 16:36:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 28/10/2019 13:48, Surafel Temesgen wrote: > > > On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing > > wrote: > > > > >     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. > > > From user prospect it is acceptable to delete and reinsert a record > with the same key value multiple time which means there will be > multiple record with the same key value in a history data but there is > only one values in current data as a table without system versioning > do .I add row end time column to primary key to allow user supplied > primary key values to be duplicated in history data which is acceptable > Yes, I understand that.  I'm saying you should also add the row start time column.