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 1vNa23-007DKs-0T for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 17:07:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vNa21-002NFb-2Z for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 17:07:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vNa0i-002JUl-0k for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 17:05:56 +0000 Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vNa0f-001Eho-3B for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 17:05:55 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id CE5957A0165; Mon, 24 Nov 2025 12:05:53 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Mon, 24 Nov 2025 12:05:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm2; t=1764003953; x= 1764090353; bh=UCA0Pw7FKxpJqBOUUxxUuTcFNCV504gt1jY+nxxv3Tg=; b=c sDrtZWlouX1V48S/zEsrZX11o4aveuty1dxWjU0PQVYsJ2xF734DMWOA8v4dxpV2 eIEQUUUia5smpLdZz6daEbkzfK5x4Vlc+tV6SPiuR6ypEgLswA/5hyWJ0iqKYy0z MmCt/rjkgIMNAkgVp8lOhBVqRyrbS+8D47vx4saYWi888SLvFi0401rGR/AgeMcr jsBTh2vEsu4hH2O8ufJ7/BsNHrguFEOZ2JOOwtakdz2xEztucH92CUOy2eyTjyJG fqyo4/BatCZ+wv6bX/BdSO851vkuPkQBAxyN+2IfQBS4VO+nKN5O0jbEfvPt5iRw MGndHvGjq6Cl0xsu8EgTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1764003953; x=1764090353; bh=U CA0Pw7FKxpJqBOUUxxUuTcFNCV504gt1jY+nxxv3Tg=; b=KZOSFRmGtau9JYvNU JIPm0MVfCG6hJ3j8a0C4GLY8/mVAoLobaVQfq4C3qpT5B9qa2XY63WhICc4QLk3z VCRG3wl4T/CRg7dhdKkO2hkvpuhaihkVgGo8eh49FEQSya/rY1s8cQtM5RM0o+1m 93Gts53gR+BErzCZGu+3Y6XszNmjbFzNVTwylJPpFSODNE9CPpzvBBSwr1uL1qQS FnarbECmuVyujxEWc0D5LsMwU8Md9iPOxoyC5oRd+NyWOdhc0r8UUMH/1wB6L1ul 8D+kUYZlYcO8+22KkhcWvuhnshdtEMKSihQcbZIyHjw9PcXMMIPdapC7JN3j7NMq 4HRWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeeludeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpeefgeevkeetjefhueekgffhffekiefhueeljeeiffetteettdffkeek leejjefhudenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgpdgvnhhtvghrph hrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgdpnhgspghrtghpth htohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheplhgruhhrvghniidrrghl sggvsegthigsvghrthgvtgdrrghtpdhrtghpthhtohepnhgvfihorghklhhltgdvtddvfe esghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehlihhs thhsrdhpohhsthhgrhgvshhqlhdrohhrghdprhgtphhtthhopehtghhlsehsshhsrdhpgh hhrdhprgdruhhs X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Nov 2025 12:05:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1764003950; bh=QmI9ZHKccfznxc+vyomTaNVqbLAyNJgBpQrjXwpG9mw=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=rKiUrM6D96tJ3PxGUC3P6lZ+IKIYae3TNdsxJDZY/yOQScO2FCgmyTV8YOUInYHXG oUSCfUj3q1v6HMw9SD0BjDN04fMcNJPeTTIlfseQ9VxeLhSpOtD2UeXlKM4JZ6Enlk CTJcdltP3GRAi3pw/PLhhmrAOWWo8Me4hEAYlXwkYMYZNXlFVa7YiTDyFjxKUIUOHb r4pyMQvjLruq9hD/2uwk5Ln5hMu2xDqq7np0GPM06cc388Hqal6NWM3DthuOv9XNFk JcDq8wJqDcZ2eWpvnfsS0X3V29gIzazhgmREtI4uyhDO2ouWIlno8R4TLn7RjoVHo2 oaiibmiDgoNLQ== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 7B58B76; Mon, 24 Nov 2025 18:05:50 +0100 (CET) Date: Mon, 24 Nov 2025 18:05:50 +0100 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Tom Lane Cc: Laurenz Albe , Calvin Guo , pgsql-general@lists.postgresql.org Subject: Re: set role command Message-ID: <202511241648.tw7dx3ga7rxk@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <955750.1764001100@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025-Nov-24, Tom Lane wrote: > Laurenz Albe writes: > > On Mon, 2025-11-24 at 16:15 +0800, Calvin Guo wrote: > > I respect your feelings, but that is not how SET ROLE works. > > The current behavior is intentional and documented in > > https://www.postgresql.org/docs/current/sql-set-role.html > > And it's also required by the SQL standard, which is very clear > that "user identifier" and "role" are different things, and > SET ROLE only changes the latter. For what it's worth, I think we break the SQL standard's security model by providing RESET ROLE and RESET SESSION AUTHORIZATION, neither of which the standard has. This means that in the standard model you have commands to lower your privilege, but once you've lowered them, you cannot return (in the same connection) to what you had. Section 4.42 "Basic security model" of the 2023 edition of the standard explains this. There is a stack of authorizations -- but when you do SET SESSION AUTHORIZATION, you don't add another cell of the stack. Instead, the current session user is replaced. They provide no way to return. The stack is used for , , triggered action, , or and the stack cell so created is automatically removed when that operation completes. Of course, I may be misreading the standard. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "No renuncies a nada. No te aferres a nada."