On Fri, Mar 7, 2025 at 12:29 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > This got me thinking more about the existing log connections messages > and whether or not they are actually all "stages". The authenticated > and authorized messages occur at nearly the same time in the > connection establishment timeline. So it seems like they aren't really > distinct stages. The messages contain different information and serve > different purposes. Looking at 9afffcb833d, which added the > authentication message, it gives the example of a database user with a > different authentication identity. The authentication message has the > auth id and the auth method. The authorized message has the db and db > username. > > So, I would call "received" and "authorized" stages and the > authentication ID message not a stage. I think I should not call these > "log_connections stages" in the docs and comments and instead call > them "log_connections options".
I think it's a valid point. If I add a hypothetical auth method in the future that authenticates, and then farms the authorization decision out to some slow-moving network machinery, would "authenticated" retroactively become a stage then? (OAuth almost does this today... but it's not quite separated enough for me to claim it as an example.) If we call them "options" instead, I guess we don't have to worry about shifting internals. > That also makes me wonder if the > "authenticated" log_connections option should actually be called > "auth_id" or something similar. To bikeshed the specific suggestion of "auth_id": both Peter E and Robert have previously expressed concern that my internal name choice of "authn_id" was too opaque, and that maybe I should have just expanded the terms. Also, I think if one option is called "authorized", the other half should probably be called "authenticated" if for no other reason than symmetry. It also matches the prefix used in the logs, for English builds. --Jacob
