From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > Target_session_attrs Target_server_type > > read-write prefer-slave, slave > > prefer-read master, slave > read-only master, prefer-slave > > I know that some of the cases above is possible, like master server with > by default accepts > read-only sessions. Instead of we put a check to validate what is right > combination, how > about allowing the combinations and in case if such combination is not > possible, means > there shouldn't be any server the supports the requirement, and connection > fails. > > comments?
I think that's OK. To follow the existing naming, it seems better to use "primary" and "standby" instead of master and slave -- primary_conninfo, synchronous_standby_names, hot_standby, max_standby_streaming_delay and such. > And also as we need to support the new option to connect to servers < 12 > also, this option > sends the command "select pg_is_in_recovery()" to the server to find out > whether the server > is recovery mode or not? The query looks good. OTOH, I think we can return an error when target_server_type is specified against older servers because the parameter is new, if the libpq code would get uglier if we support older servers. > And also regarding the implementation point of view, the new > target_server_type option > validation is separately handled, means the check for the required server > is handled in a separate > switch case, when both options are given, first find out the required server > for target_session_attrs > and validate the same again with target_server_type? Logically, it seems the order should be reverse; check the server type first, then the session attributes, considering other session attributes in the future. Regards Takayuki Tsunakawa
