On Mon, Mar 18, 2019 at 9:33 PM Haribabu Kommi <kommi.harib...@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
