Re: CREATE SCHEMA ... CREATE DOMAIN support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
Date: 2026-09-04 19:30:38
Message-ID: 1584523.1788550238@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Fri, Sep 04, 2026 at 10:21:52AM -0400, Tom Lane wrote:
>> What would you have us do differently?

> I recommend reverting the v19 CREATE SCHEMA changes, unfortunately. The
> thread started with what smelled like low-hanging fruit: let users write
> "CREATE SCHEMA myschema CREATE DOMAIN mydomain" instead of "CREATE SCHEMA
> myschema; CREATE DOMAIN myschema.mydomain". That led to a9c350d silently
> changing the meaning of CREATE SCHEMA statements that v18 already accepts.
> Since the benefit of supporting "CREATE SCHEMA myschema CREATE DOMAIN
> mydomain" is so modest, it doesn't take much of a problem to outweigh that
> benefit.

Well, you have a point. There's pretty nearly nothing that's
well-designed about CREATE SCHEMA subcommands: as you say, the syntax
is shaky, and the namespace visible to subcommands is unclear, and
the whole business of re-ordering subcommands is debatable, and even
if all those things were fixed the benefit of the entire feature is
marginal. So maybe we should just say that our legacy implementation
is what it is and we will mark it deprecated rather than putting any
effort into improving it. I'd like to see more than one vote in favor
of that before I do it, though.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-09-04 19:40:29 Re: pg_*_advice: tsv load failure, etc.
Previous Message Daniel Gustafsson 2026-09-04 19:29:03 Re: Fix detection of truncated zstd-compressed backups