From: | Jean Baro <jfbaro(at)gmail(dot)com> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Trevor Gross <t(dot)gross35(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: System Versioned Temporal Table |
Date: | 2022-02-15 20:10:43 |
Message-ID: | CA+fQeenbJDqNboYgFX34xhBA2Ygvz6T34raOU=EDti_W0Gb5KQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Would these best practices be applicable by PostgreSQL to help avoid
breaking changes for temporal tables?
https://blog.datomic.com/2017/01/the-ten-rules-of-schema-growth.html
Thanks
On Tue, Feb 15, 2022 at 5:08 PM Vik Fearing <vik(at)postgresfriends(dot)org> wrote:
> On 1/24/22 00:16, Corey Huinker wrote:
> >> - Table schemas change, and all (SV active) AV items would logically
> >> need to fit the active schema or be updated to do so. Different story
> >> for SV, nothing there should ever need to be changed.
> >>
> > Yeah, there's a mess (which you state below) about what happens if you
> > create a table and then rename a column, or drop a column and add a
> > same-named column back of another type at a later date, etc. In theory,
> > this means that the valid set of columns and their types changes
> according
> > to the time range specified. I may not be remembering correctly, but Vik
> > stated that the SQL spec seemed to imply that you had to track all those
> > things.
>
> The spec does not allow schema changes at all on a a system versioned
> table, except to change the system versioning itself.
> --
> Vik Fearing
>
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-02-15 20:23:30 | Re: adding 'zstd' as a compression algorithm |
Previous Message | Robert Haas | 2022-02-15 20:09:37 | Re: adding 'zstd' as a compression algorithm |