Re: BUG #17909: CREATE SCHEMA AUTHORIZATION sch CREATE TABLE foo ( id INT ) will coredump

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: hysong0101(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17909: CREATE SCHEMA AUTHORIZATION sch CREATE TABLE foo ( id INT ) will coredump
Date: 2023-04-27 23:05:22
Message-ID: ZEr/shjg+8TClUm/
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

On Thu, Apr 27, 2023 at 06:28:28PM +0800, Richard Guo wrote:
> I noticed that in CreateSchemaCommand there is logic that fills schema
> name with the role name if it is not specified. Do you think we can
> save the new-filled schema name into CreateSchemaStmt.schemaname there?

It's actually much trickier than that, on second look, as a RoleSpec
is embedded in this portion of a query because we need to support
query assigns neither role name nor schema name we could rely on at
transformation for the objects:
create schema authorization current_role create table aa (a int);

Anyway, semantically, something could go very wrong if we decide to
enforce a schema name for the objects based on the RoleSpec at the
time of transformation, because we may finish by executing the CREATE
SCHEMA command under an entirely different context than what we could
assign. So, I think that we should do the following in the
transformation path if an object is schema-qualified:
- Fail immediately if there is no schema and no role name at hand,
just give up. This needs a new error message, say:
"CREATE specifies a schema (%object_schema) without providing a schema
- If there is a role name, aka RoleSpec points to a ROLESPEC_CSTRING,
use it as a comparison with the objects schema-qualified. Note that
there is no case for public, because we would fail on
get_rolespec_oid() when the schema is created.

There is also a very fancy case, if "foo" matches to the role that
would be assigned by GetUserIdAndSecContext() when executing the
schema command:
create schema authorization session_role create table foo.aa (a int);

One could say that this should work, and my proposal would cause an
error to make the query more predictible at an earlier step. IMO, I
think that this is just saner. And this case crashes today like the

Any thoughts or objections about doing that?

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2023-04-27 23:08:01 Re: BUG #17903: There is a bug in the KeepLogSeg()
Previous Message Nathan Bossart 2023-04-27 21:47:46 Re: BUG #17903: There is a bug in the KeepLogSeg()