Hello, Thank you for the constructive feedback.
> Your proposal will add more confusion to the already-confused logging-related > GUCs. > I wouldn't introduce a new GUC that depends on the stage of other GUC as you > proposed. Agreed, coupling a new GUC with "log_connections" is likely to lead to extra confusion. > There are 3 stages: connect (received), authorized (authenticated), > disconnect. I've taken connection stages and terminology from the existing log messages. The reason I have separated "authorized" and "authenticated" are [1] and [2] usages of "log_connections"; "received" is mentioned at [3]. >> Example: log_connection_stages=’authorized,disconnected’. > would turn the boolean value into an enum value I have thought about enums too, but we need to cover arbitrary combinations of message types, for example log only "received" and "disconnected". Hence the proposed type "string" with individual values within the string really drawn from an enum. > merge log_connections and log_disconnections into a new GUC (?) and deprecate > them. Are there any specific deprecation guidelines ? I have not found any after a quick search for GUC deprecation in Google and commit history. A deprecation scheme could look like that: 1. Mention in the docs "log_(dis)connections" are deprecated in favor of "log_connection_stages" 2. Map "log_(dis)connections" to relevant values of "log_connection_stages" in code if the latter is unset. 3. Complain in the logs if a conflict arises between the old params and "log_connection_stages", with "log_connection_stages" taking the precedence. Regards, Sergey [1] https://github.com/postgres/postgres/blob/3f8148c256e067dc2e8929ed174671ba7dc3339c/src/backend/utils/init/postinit.c#L257-L262 [2] https://github.com/postgres/postgres/blob/02c408e21a6e78ff246ea7a1beb4669634fa9c4c/src/backend/libpq/auth.c#L372 [3] https://github.com/postgres/postgres/blob/master/src/backend/postmaster/postmaster.c#L4393
