Nathan Bossart <[email protected]> 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'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.
regards, tom lane
