On 12/02/2026 13:43, Matheus Alcantara wrote:
> 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?
If we conclude that it isn't worth adding any references to other
schemas, I believe we must let the user decide if the tables should be
created or not, since it would IMHO significantly reduce the range of
use cases for which this feature can be employed.
Since we're brainstorming, imagine the following scenario:
A schema contains hundreds of tables referencing objects in other
schemas and the user creates a new schema based on it. Currently, the
problematic tables are created only partially, and the user is warned
about what has gone wrong. Now, the user has to decide if the incomplete
tables are worth keeping or not, and in case they're not, DROP them
manually.
What do you think about introducing a clause similar to COPY ..
ON_ERROR? Something like
CREATE SCHEMA s2 LIKE s1 INCLUDING ALL ON ERROR [SKIP/IGNORE/ ...]
CREATE SCHEMA s2 LIKE s1 INCLUDING ALL ON ERROR [STOP/ABORT/...]
Best, Jim
