Store db connection parameters in a their own class #2129
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The connection parameters (such as dbname, user, host, ...) are stored in their original format and not concatenated into a conninfo string any more. We are now using a different database connection function from libpq that takes them in this form. This allows us to get rid of the code that transforms those parameters into the conninfo string that takes various forms of connection parameters into account, especially around the URI form of the connection parameters. The libpq has this code anyway, see also the last parameter "expand_dbname" of the PQconnectdbParams() function (https://www.postgresql.org/docs/current/libpq-connect.html). This also allow us to have slightly different database connection parameters for different database connection. This is used here to add the connection id into the fallback_application_name parameter. This connection id also reported when using --log-sql. This way you can correlate the ids from the log with the information shown in pg_stat_activity. This commit looks large, because it changes the type std::string to connection_parameters_t in many places. I have kept the parameter name "conninfo" in an effort to keep the commit small, the next commit will change that also.
This is really part of the previous commit but was factored out to keep that one reasonably legible.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The connection parameters (such as dbname, user, host, ...) are stored in their original format and not concatenated into a conninfo string any more. We are now using a different database connection function from libpq that takes them in this form. This allows us to get rid of the code that transforms those parameters into the conninfo string that takes various forms of connection parameters into account, especially around the URI form of the connection parameters. The libpq has this code anyway, see also the last parameter "expand_dbname" of the PQconnectdbParams() function (https://www.postgresql.org/docs/current/libpq-connect.html).
This also allow us to have slightly different database connection parameters for different database connection. This is used here to add the connection id into the fallback_application_name parameter. This connection id also reported when using --log-sql. This way you can correlate the ids from the log with the information shown in pg_stat_activity.
This commit looks large, because it changes the type std::string to connection_parameters_t in many places. I have split the work into two commmits, in the first I have kept the parameter name "conninfo" in an effort to keep the commit small. The second commit renames "conninfo" to "connection_params" everywhere.