Re: CREATE SCHEMA ... CREATE DOMAIN support

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Wed, Sep 09, 2026 at 12:44:51PM -0400, Tom Lane wrote:
>> 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 agree that the risk is not zero, but it would be nice to salvage
something from this work ;-). Also, I can't help noticing that we
have claimed full compatibility with F311-01 for years, and that's
been a lie up till these patches fixed it.

>> 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?

Exactly.

> 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.

It turns out that I had included that bit in the back-patched versions
of 3045a25ba (CVE-2026-6464), which maybe was overly bold of me but
I figured that that was the state of the code that we'd validated
while testing master. So it's a done deal now and undoing it in v19
wouldn't improve matters.

I've finished a patch that reverts 049b742da and d51697484 (attached),
and looking at it, I can't help noticing that those commits in
themselves don't create any backwards-compatibility issues: they
only add more subcommand types to what CREATE SCHEMA accepts. The
fundamental problem here is just that a9c350d9e changes existing
behavior. So perhaps another way forward could be to back off that
decision in some way that preserves the behavior in existing cases
while not re-ordering these additional subcommand types. I suppose
it's too late to start designing something like that for v19, but
maybe it'll be possible to un-revert the attached in v20.

regards, tom lane