Re: Proper way to clean-up connection for reuse (`DISCARD ALL` and default role)

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :

> Logan MAUZAIZE <logan(dot)mauzaize(at)gmail(dot)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
>