Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wFo2C-005ZTU-0h for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 06:59:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFo2B-000D5k-1G for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 06:59:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wFo2B-000D5c-0I for pgsql-hackers@lists.postgresql.org; Thu, 23 Apr 2026 06:59:35 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wFo28-00000002bdU-3e4T for pgsql-hackers@postgresql.org; Thu, 23 Apr 2026 06:59:34 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-409de4132b5so4050079fac.1 for ; Wed, 22 Apr 2026 23:59:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776927570; cv=none; d=google.com; s=arc-20240605; b=f6A6PbabHTMENU/oTi0D3AyD1K/uDppbyGrPYvT9TX2aJxpaSKyV17o/5dob2EDVoi C0ZfWpJiR89rASMrbkCHJHHOcXeTFnJXN+BJE/kyoWXMacCswH3VXK65PYZg//PBt/bm NE8d1K1pTS0vWrgpZLk/AIyPsE4PXEzfHGXsKAQE/WrMnLvdtdRm2pabrV7p8RZt4MPG S64EBJLo5RdKZH3NdOJZ+rdOpRPMk/ZFpnIdD4eh7AJYVs6sJb5er1Tjmo8zz/YRHFqi KMU+9neR68ZQZ8q0ebtn1ER3NPOGyJRmcEVJdmlyFp7Kh5GOXdmv/UWPLH0FmaF3V/oA U6vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=TqflE3urB99vF84w0SEWNb5NeempUGe/J26rBUGuhCs=; fh=33OU7BWuulPFH378PdKTnpeW+jw3IP20DTmpLDeQ3pE=; b=BehrvvJkcTDG1ak9hgV7jkX5P/n86i7FwXmzUH1F5HWMCisoiFXSzrHqA/eHTJpeO5 7ByJbm5IziERtzjWsJwmXXPAYF+4UzNpYTzgMbHRPz2MIHg6BgznmZE6Np/XARz4zCXK KhWpgDnTaPxEAbeycyuquD/CPmnwFhegc00H4BTuXycz7w7VRMp4BV6kg9W7diapqxHs cIsYUYwKfCQKlmYG8ZhexgCi857Q3SIXNHezV4yG907//ZM5X+bZ9ooF0bc4mRV29lVM 2Cko5xwZC0OkBedcYvoBDAnbX7U7nAMpndFU1JDGNy9JtrgZcI2ZZZ+U0HWTnIil+R9U CP5w==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776927570; x=1777532370; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=TqflE3urB99vF84w0SEWNb5NeempUGe/J26rBUGuhCs=; b=KuqxEMKm0gKrI6f1QUDqf58wXW1UXNKVqKr+0ytqK1K3eo9BmMQZGQTaF/r3LXYdxL cohYFgC6nagSine8mA+49oQjMPuIFFkfUcirC2Gs98g/wnzviJ79Xaf6rnGn4+OpoR+u 1aNRo/0O+ppNLa6ZpU43BXQ2QaG3i4CRnBK3q+gVfGOlTYuIvohmMjhnwPctHMbLb1FN Qk7AW+qELI6iZYd01SuTJN5aloW5xactYOvQR85RN8BLIlERYJiS57KtCb+J21lXwoP3 UM396whqWYmJ3W3Wx8dv8Bkzhkp0LxM0L8Jqv8pFBBAw9YW1XonAZMpyKndSbop/IRq9 E2GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776927570; x=1777532370; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TqflE3urB99vF84w0SEWNb5NeempUGe/J26rBUGuhCs=; b=plzhegBkS0ZopPQEchimK4siXAtl5i7GEXFPF+bu+RKQlrkcMq2jqQL0XIo+FwjQVZ c9pcG7D/7F8zcR2Q/Ge5F5BcX0sSsfiCbfXWKaqacr7lTfpl2S6l5XBR+sgHFRpF1naN feMDipISkQo3qPfijs0oRUsPVdVWS9U8gJ1Kk7FhN44UmHj96dCgD49b3EQknFhdfiie oIN2lZcswJv2NVfo3q2YJLN+O/WyGywHOxK5/4zaf1E4cyi9HtwF/BqWF6wB11C2Up3R avVDhmmeCPwzwa85gf7hyzvyLUzg/unLddZ/ZPd3qbuT+8qG0BzC9p2Hy1a2643WMlB7 yNyQ== X-Gm-Message-State: AOJu0YxxpLN+pADOB4U9FxYqYG0LqTselXvaLrn8FYJIFDLZD9YCe0VI KjeL2d+8O/RReX1JyjY7+teaoOkeTpa0/+h/X/5zfbuXUWY7eRS4tBBc8oJTFlzPwpgwxDQ33io u/OXwhQXKkj5ddPyVC/ZjcaIa6UpcEuSBWVRPt64= X-Gm-Gg: AeBDies8dcvswHUjiMQAscQfAPHe5IIOqxK2vitT7OvWhwOWpHkTN/DZ7NLsM095+qL GF0+7gBxFBmUPPz7OpjR6zg3LFac2iribGDnibJ1SFmSYYPoyyMmBXVKGLZXRTKKvNJHBwS2WAc bewf2ee+akjyMavVQ6d9AAzP73g7UoZQBkPE4paj+XZ3Obmq4yIYI4RzVroLn9KWGTeEmTbrDU5 wFQz63WDxib/0O3gx+fhQ6d6XnplWo5cczrUT+8/8Recs0o1Y5rBwPOpnncynUvVGVqp9TRswkP g0pYZF06MBKnXwFjHPDNoPxSK41wQ805vK2QSR1KuZVn6i2lPkY= X-Received: by 2002:a05:6870:c0e:b0:42f:eda7:42f8 with SMTP id 586e51a60fabf-42feda78c84mr364077fac.8.1776927570608; Wed, 22 Apr 2026 23:59:30 -0700 (PDT) MIME-Version: 1.0 From: Zach Manifold Date: Wed, 22 Apr 2026 23:59:19 -0700 X-Gm-Features: AQROBzBZD6_kx46sq_Qipf4TOMTGJN6MeeRSHWivagCr3wXSovpOvBwMxkeACGM Message-ID: Subject: Proposal: DROP ROLE ... REASSIGN OWNED TO ... To: pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi all, First-time hacker here wanting to get into the community. I am proposing a fairly small quality of life feature for role management which is to allow users to reassign ownership within the same command as dropping a role. Currently you must reassign ownership prior to dropping a role (if it owns anything) such as: REASSIGN OWNED BY role1 [, ...]TO role2; DROP ROLE role1; I am thinking of the usage: DROP ROLE role1 [, ...] REASSIGN OWNED TO role2; Original behavior would remain if not specifying the option: DROP ROLE role1 [, ...]; For the implementation, I was thinking of adding a RoleSpec into DropRoleStmt to hold the "assigned to role" which would be NULL unless otherwise provided by the option. The grammar for DropRoleStmt would be updated to add a new option (opt_reassign) to optionally provide the RoleSpec. There are other cases in the DropRoleStmt grammar such as users and groups - I'm wondering if this would apply to those as well (e.g., DROP USER ..., DROP GROUP ...) Within the DropRole command (after all the initial validity checks,) I was thinking to check if this value was non-null and create a ReassignOwnedStmt before making a call to ReassignOwnedObjects before the foreach loop is called to actually remove the list of roles. My one concern is the possible failure mode - is it possible for the reassignment to work but the role to fail to drop? Is this preventable? I'm not sure how to "cleanly" approach this type of safety where I can assure that both of these operations must succeed rather than reassigning ownership and failing to drop a role. Are there any other failure modes I should be considering? Would like to hear from anyone if there's any appetite for this and your thoughts on how this can be approached. Regards, - Zach Weaver