Re: Add CREATE SCHEMA ... LIKE support

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, "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-11 20:51:57
Message-ID: CAKFQuwYqck00fRp_xr6TVjBkQKbcJwWcQ6kTH+jipC0EzsPSkQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, February 11, 2026, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
wrote:

>
> 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).
>
> Another issue is to handle complex relations like the following:
> - Function A returns a boolean type
> - Custom DOMAIN type call function A on CHECK constraint
> - Function B return/use a type of custom DOMAIN
>
> What we should create first? It can have functions that depends on
> domains, so domains should be created first, but it can also have
> domains that depends on functions, so functions would need to be created
> first. This would be trick to fix.
>

This is a solved problem in pg_dump, no? It understands and follows the
dependency graph. Even allows schema-only dumps.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-02-11 21:00:51 Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Previous Message Daniel Gustafsson 2026-02-11 20:39:20 Re: IPC::Run::time[r|out] vs our TAP tests