Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1psG7F-0007O1-AR for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Apr 2023 04:53:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1psG7D-0001lU-Qb for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Apr 2023 04:53:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1psG7D-0001lL-IC for pgsql-bugs@lists.postgresql.org; Fri, 28 Apr 2023 04:53:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1psG7A-005Vos-V8 for pgsql-bugs@lists.postgresql.org; Fri, 28 Apr 2023 04:53:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 33S4rdDf1273139; Fri, 28 Apr 2023 00:53:39 -0400 From: Tom Lane To: Michael Paquier cc: Richard Guo , hysong0101@163.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17909: CREATE SCHEMA AUTHORIZATION sch CREATE TABLE foo ( id INT ) will coredump In-reply-to: References: <17909-f65c12dfc5f0451d@postgresql.org> <1237482.1682639329@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Fri, 28 Apr 2023 12:56:38 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1273137.1682657619.1@sss.pgh.pa.us> Date: Fri, 28 Apr 2023 00:53:39 -0400 Message-ID: <1273138.1682657619@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Fri, Apr 28, 2023 at 11:29:11AM +0800, Richard Guo wrote: >> BTW, the comment states that CreateSchemaStmtContext.stmtType is "CREATE >> SCHEMA" or "ALTER SCHEMA". But it seems that there is no chance to set >> it to "ALTER SCHEMA". So should we update that comment, or go even >> further to remove CreateSchemaStmtContext.stmtType since it is not used? > Indeed. I'd be OK with adjusting the comment, without removing > stmtType to keep some consistency with CreateStmt, and it could be > useful for debugging, perhaps.. (See 46379d6 as one origin point). I'd be okay with just dropping that field. It seems to be much older than 46379d6, and if it ever had any real use it doesn't now. (There's no ALTER SCHEMA in the SQL spec at all, let alone one that has some overlap with CREATE SCHEMA options, so I don't foresee a future use either.) regards, tom lane