| From: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
|---|---|
| To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
| Cc: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add CREATE SCHEMA ... LIKE support |
| Date: | 2026-02-10 11:52:20 |
| Message-ID: | CAB-JLwb8VjgFO+Bb9PmLHu5UggqGGt=9V3=QD+j7_EQ49YaYvw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Em ter., 10 de fev. de 2026 às 07:09, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
escreveu:
> Even if parent and children live in the same schema, they become
> detached in the new copy -- I'd argue that this one is a bug.
>
I think the approach will fail at some point if you keep using CREATE TABLE
LIKE, because so many things will be incomplete or at least strange, that
you'll have to redo many of them.
Sequence values will be shared with the old table.
Constraints/Indexes names will have to be renamed.
Partitioned tables will have to be attached.
Foreign Keys are not created either.
These are the ones we've found so far, but other inconsistencies will
certainly appear.
So I don't know if CREATE TABLE LIKE is the best way to do this work.
regards
Marcos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | lakshmi | 2026-02-10 11:53:02 | Re: Metadata and record block access stats for indexes |
| Previous Message | Jim Jones | 2026-02-10 11:41:07 | Re: Add CREATE SCHEMA ... LIKE support |