From: Haribabu Kommi [mailto:kommi.haribabu@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
becausethe 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
othersession attributes in the future.
Regards
Takayuki Tsunakawa
