From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | AbdelAziz Sharaf <mickelpower75(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Feature Request] Schema Aliases and Versioned Schemas |
Date: | 2024-12-17 06:16:45 |
Message-ID: | CAExHW5uGn496_sqCuwbGZYDs25B=GqwDrZCTkMtB5kmtKBJ=CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 17, 2024 at 10:01 AM AbdelAziz Sharaf
<mickelpower75(at)gmail(dot)com> wrote:
>
> No
> when specifying search_path, we build another schema, where each duplicate data must be inside
> what I suggested is to have versions/aliases for schemas and any duplicate table/view/... could be inherited if duplicate with all data inside and when any version/alias is dropped and another version/alias has the same table it's preserved, with data inside
> that's different behavior where tables attach to schema and if inherited from version/table it may create/reuse it with/without data inside
> and this behavior is resource lightweight for migrations
> it also could introduce shared tables between schemas
>
> Hope this helps
>
> > Note : sorry for repeating the msg, I realized the replay was only to Ashutouh, not the messaging list, think that's why I didn't have any replay, it may be lost
>
Hi AbdelAziz,
IIUC, what you want to do is this
1. Create a schema for every version of data
2. The tables which do not change across versions are shared by the
corresponding schemas
3. The tables which change with version are created and copied to the
corresponding schema from (older?) schema
If that's correct, it might be possible to implement it with updatable
views - one view per schema pointing to the underlying shared table.
The view might be able to accommodate some changes to table schema
without actually creating a new table.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-12-17 06:26:02 | Re: per backend I/O statistics |
Previous Message | Bertrand Drouvot | 2024-12-17 05:15:06 | Re: Track the amount of time waiting due to cost_delay |