Re: Add CREATE SCHEMA ... LIKE support

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