Re: CREATE SCHEMA ... CREATE DOMAIN support

On Wed, Sep 09, 2026 at 12:44:51PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> > On Wed, Sep 09, 2026 at 06:53:58PM +0300, Heikki Linnakangas wrote:
> >> Reverting seems like the safest thing to do. This is a really niche thing,
> >> but whatever behavior we pick, we'll be stuck with it for a long time. If
> >> we're not 100% certain about the new behavior, better to take a step back
> >> and discuss and design it with more time.
>
> > +1
>
> After looking at the git history a bit, the relevant commits are
>
> Branch: master Release: REL_19_BR [049b742da] 2026-06-23 14:12:03 -0400
> psql: Tighten heuristics for BEGIN/END within CREATE SCHEMA.
> Branch: master Release: REL_19_BR [d51697484] 2026-04-06 15:16:25 -0400
> Support more object types within CREATE SCHEMA.
> Branch: master Release: REL_19_BR [404db8f9e] 2026-04-06 15:16:25 -0400
> Execute foreign key constraints in CREATE SCHEMA at the end.
> Branch: master Release: REL_19_BR [a9c350d9e] 2026-04-06 15:16:25 -0400
> Don't try to re-order the subcommands of CREATE SCHEMA.
>
> It looks like it might be possible to revert a9c350d9e and d51697484
> while keeping 404db8f9e, which would preserve a feature clearly
> required by the SQL standard (F311-01, "Support for circular
> references in that <referential constraint definition>s in two
> different <table definition>s may reference columns in the other
> table") while not breaking compatibility with our pre-19 behavior.
> Any opinions about whether that's a good thing to try to do, rather
> than a wholesale revert?

I don't have concerns specific to that change. In general, since the changes
were part of a composed series, I'd ascribe non-negligible risk to keeping
just part of the series. Maybe leave it in master but revert from v19? On
the other hand, the change is contained to a low-risk topic. I don't have a
strong preference between those choices.

> I'm also inclined to keep this bit of 049b742da:
>
> This patch also fixes what seems to me (tgl) a small bug: \;
> would reset BEGIN/END detection even when inside parens or BEGIN.
> That's unlike what a plain semicolon would do, and no such effect
> is suggested by the documentation.

What's a command that notices the difference? Something like a sql-standard
function body where the user backslashed the semicolons even though it wasn't
necessary?

I agree it's conceptually right to keep that bit. Resetting detection makes
sense at an unescaped semicolon that ends the query buffer, but that doesn't
extend to an escaped semicolon. I'm somewhat struggling to map out the
implications for existing scripts, but that's fair for a major release.