Re: Add CREATE SCHEMA ... LIKE support

From: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add CREATE SCHEMA ... LIKE support
Date: 2026-02-06 15:52:45
Message-ID: CAFY6G8e40cZXaamekPJFMbcd9nHRVbkqHhUwoVs0YfayuscYqw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/02/26 12:23, Jim Jones wrote:
>
>
> On 06/02/2026 15:42, Matheus Alcantara wrote:
>> On 06/02/26 11:35, Jim Jones wrote:
>>> So EXCEPT instead of EXCLUDING and LIMIT TO instead of INCLUDING. Of
>>> course, assuming the proposed syntax isn't already defined in the SQL
>>> standard.
>>>
>>
>> Yeah, it could be an option but IMHO adding the LIKE on CREATE SCHEMA
>> sounds more similar to what we already have for CREATE TABLE ... LIKE.
>>
>> Although I prefer the CREATE SCHEMA LIKE syntax I'm open to discuss
>> about other syntaxes.
>
> Just to be clear, I also like the CREATE SCHEMA <name> LIKE
> <source_schema> syntax. I was just suggesting to consider changing
> EXCLUDING and INCLUDING to EXCEPT and LIMIT TO, respectively. Just to
> make it more consistent with IMPORT FOREIGN SCHEMA, although I find
> INCLUDING and EXCLUDING way more intuitive :)
>

The idea of INCLUDING and EXCLUDING is to specify objects that should
be included/excluded, e.g INCLUDING ALL EXCLUDING INDEX EXCLUDING VIEW

It seems to me that LIMIT TO and EXCEPT is more related to specify
which objects you want to include/exclude e.g "EXCEPT users" (where
users is a table)

(While I'm writing this email, Hubert Depesz has shared a similar
comment about this [1])

[1] https://www.postgresql.org/message-id/aYYKQDln_qjA_CdA%40depesz.com

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2026-02-06 16:05:02 Re: Add CREATE SCHEMA ... LIKE support
Previous Message Sami Imseih 2026-02-06 15:47:07 Re: [PATCH] Add last_executed timestamp to pg_stat_statements