RE: Libpq support to connect to standby server as priority

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