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