Hi Tom, Regarding "some" missing context as stated, only thing that has been done is assigning a default role to the login one with `ALTER ROLE <login> SET ROLE <default>`.
If it can help: ```sql SELECT version(); -- PostgreSQL 14.12 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6), 64-bit ``` Le lun. 20 janv. 2025 à 18:06, Tom Lane <t...@sss.pgh.pa.us> a écrit : > Logan MAUZAIZE <logan.mauza...@gmail.com> writes: > > 1. clarify if `DISCARD ALL` behavior is the expected one or is it a bug? > > DISCARD ALL is documented to do SET SESSION AUTHORIZATION DEFAULT, > and for me it does that, that is "session_authorization" reverts to > the login role, "role" reverts to "none", and as a consequence > current_user becomes the login role. I'm bemused by your claim > that "reset role" can cause current_user to become something > other than the current session_authorization ... maybe you are > doing something strange with setting "role" as an ALTER USER SET > or ALTER DATABASE SET property? Your example seems to omit > necessary setup. > > (If you are doing that, you probably need to be running the latest > minor releases to see the same behavior I'm seeing; the changes for > CVE-2024-10978 affected some behavior that's related to this.) > > One thing that is not well documented is that RESET ALL doesn't > touch either "session_authorization" or "role". I suppose the > reasoning is that those things are session properties specified > by the SQL standard. It's a little weird, but it's stood for > many years and I doubt we'd consider changing it now. > > regards, tom lane >
