Re: CREATE SCHEMA ... CREATE DOMAIN support

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-04-06 02:29:05
Message-ID: CACJufxEwkAJuCutLQdsxCOJkAvDS=9KgbphMVkXtQP8te=nciA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 6, 2026 at 4:15 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Here's a revised patchset that I think is pretty close to committable.
> I reorganized it some compared to v11: 0001 is still about the same,
> but the business with allowing circular foreign keys is now in 0002,
> because it seems like that bears directly on whether we should
> consider 0001 acceptable. And then I squashed all the object-type
> additions into 0003, because dealing with them all at once seemed
> simpler.
>
> I rewrote 0002 rather heavily, mainly because it assumed it could
> scribble on the input query tree which I don't think is okay.
> The functionality is still the same though.
>

transformCreateSchemaStmtElements you mentioned

* Note it's important that we not modify the input data structure. We create
* a new result List, and we copy any CREATE TABLE subcommands that we might
* modify.

But there is still no explanation about why it's not ok to scribble on
the input query tree.
V13-0002 looks great, and it is way more intuitive than my approach!
Thanks!

+ DeconstructQualifiedName(qualified_name, &obj_schema, &obj_name);
+ if (obj_schema != NULL &&
+ strcmp(context_schema, obj_schema) != 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_SCHEMA_DEFINITION),
+ errmsg("CREATE specifies a schema (%s) "
+ "different from the one being created (%s)",
+ obj_schema, context_schema)));

There is no tests for the above. It would be better to have one dummy
test verify the error message.

it would be better change to
+ errmsg("CREATE specifies a schema (%s) different from the one being
created (%s)",
It's better for regex pattern searching, for new line you need to know
how to escape.

+ (errcode(ERRCODE_INVALID_SCHEMA_DEFINITION),
The leading parenthesis is not needed.

> I was kind of sad that 0003 didn't support functions/procedures,
> because (a) the SQL spec requires those in CREATE SCHEMA, and
> (b) they are a flagship feature for Postgres, mainly because they
> are such a critical aspect of extendability. So I added that,
> which only required adding CreateFunctionStmt to the set of
> supported node types in transformCreateSchemaStmtElements.
>

I guess at the time, I wasn't aggressive enough to consider CREATE
SCHEMA CREATE FUNCTION.

I saw the "Author" line in commit messages v13-0002 and v13-0003.
You should be added as an author on both v13-0002 and v13-0003.
Your changes simplified 0002 a lot, and you added the other CREATE
SCHEMA subcommands to 0003.

Except for the above issue, v13 all looks good to me.

--
jian
https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinya Kato 2026-04-06 02:32:03 Re: remove autoanalyze corner case
Previous Message Andres Freund 2026-04-06 02:09:48 Re: Our ABI diff infrastructure ignores enum SysCacheIdentifier