On Mon, Mar 18, 2019 at 9:33 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
> While working on implementation of target_server_type new connection option for the libpq
> to specify master, slave and etc, there is no problem when the newly added target_server_type
> option is used separate, but when it is combined with the existing target_session_attrs, there
> may be some combinations that are not valid or such servers doesn't exist.
>
> 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 really dislike having both target_sesion_attrs and
target_server_type. It doesn't solve any actual problem. master,
slave, prefer-save, or whatever you like could be put in
target_session_attrs just as easily, and then we wouldn't end up with
two keywords doing closely related things. 'master' is no more or
less a server attribute than 'read-write'.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
