Re: BUG #17909: CREATE SCHEMA AUTHORIZATION sch CREATE TABLE foo ( id INT ) will coredump
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Richard Guo <guofenglinux@gmail.com>
Cc: hysong0101@163.com, pgsql-bugs@lists.postgresql.org
Date: 2023-04-27T23:05:22Z
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 CURRENT_ROLE, CURRENT_SESSION and SESSION_USER. For example, this 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 name." - 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 others. Any thoughts or objections about doing that? -- Michael
Commits
-
Fix crashes with CREATE SCHEMA AUTHORIZATION and schema elements
- a9212716b3bf 11.20 landed
- 63f7e91ecf9f 12.15 landed
- 7e95a33b42e7 13.11 landed
- d29eba1987cb 14.8 landed
- b9ad73ad250b 15.3 landed
- 4dadd660f071 16.0 landed