Thanks for testing this patch! On Thu Feb 12, 2026 at 7:45 AM -03, Jim Jones wrote: >> I've fixed this by adding a WARNING message and skipping the table >> partition. > > Nice! The system now issues a WARNING if the parent table lives in a > different schema > > CREATE SCHEMA s3 LIKE s2 INCLUDING ALL; > WARNING: skipping partition "s2.p1" because its parent table is in > schema "s1" > > I'm wondering if the same should apply for a schema containing only the > parent table. Currently, it creates a partitioned table with 0 partitions: >
Yes, it sounds a good idea to log a WARNING to mention that table partitions are on different schema and only the parent table will be copied in this case. I'll include this on the next version. >>> Comments are also being ignored, but I guess it was already mentioned >>> upthread:> It should work... I'll investigate this. > I believe it's an unrelated bug at expandTableLikeClause(). I opened a > new thread for this: > > https://www.postgresql.org/message-id/e08cb97f-0364-4002-9cda-3c16b42e4136%40uni-muenster.de > Thanks, I'll find some time to review this patch. >> I also want to mention that I don't think that we would be able to >> properly re-created 100% all objects from the source schema into the new >> schema. Some objects will be hard to copy and can still generate bougy >> objects like functions for example as David mention on [1] (we can >> support some kind of functions but some others will be hard). > > > Yeah. I also think we need to draw a line at some point and document all > limitations. Specially regarding cross-schema dependencies, where it > might skip the dependencies for some objects (e.g. partitioned tables) > but works with others, e.g. functions in check constraints: > > CREATE SCHEMA s1; > CREATE OR REPLACE FUNCTION s1.f(text) > RETURNS boolean LANGUAGE sql AS > $$ SELECT $1 <> ''; $$; > > CREATE SCHEMA s2; > CREATE TABLE s2.t (id int, name text CHECK (s1.f(name))); > > CREATE SCHEMA s3 LIKE s2 INCLUDING ALL; > > \d s2.t > Table "s2.t" > Column | Type | Collation | Nullable | Default > --------+---------+-----------+----------+--------- > id | integer | | | > name | text | | | > Check constraints: > "t_name_check" CHECK (s1.f(name)) > > \d s3.t > Table "s3.t" > Column | Type | Collation | Nullable | Default > --------+---------+-----------+----------+--------- > id | integer | | | > name | text | | | > Check constraints: > "t_name_check" CHECK (s1.f(name)) > Definitely agree. I've started to add some documentation about the behaviour and limitations on the v3 version but I still need to include more information. I'm wondering if in this case we should not include the check constraint since it reference a function from a different schema and have the same behaviour that we have for partitioned tables and FK's. It seems to me that skipping any kind of object that reference another object from a different schema would be more resanable. Having this behaviour for just some objects(e.g partitioned tables, FKs) seems a bit confusing, what do you think? > I'll take a look at the code later today or tomorrow. > Thank you! -- Matheus Alcantara EDB: https://www.enterprisedb.com
