On 05/03/18 22:18, Satyanarayana Narlapuram wrote:
Please see the attached patch with the comments.Changes in the patch: A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries. BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1 downgrades to v3.0 upon receipt of this message. FE falls back to v3.0 if 3.1 is not supported by the server. >> I hadn't really thought deeply about whether redirection should happen before or after authentication. For the most part, before seems better, because it seems a bit silly to force people to authenticate just so that you can tell them to go someplace else. Also, that would lead to double authentication, which might for example result in multiple password prompts, which users might either dislike or find confusing. Yes, redirection before authentication would avoid multiple password prompts.
I think we should have this feature. I can see a redirect being useful in some similar cases like HTTP redirects are useful, but a database server is not a web server. There are no redirects in IMAP or most other protocols, either.
This would also require modifying every client library to honor the redirect.
How would the redirect behave with TLS certificate verification? If you are redirected from "foo-server" to "bar-server", but the original connection string was "host=foo-server sslmode=verify-full", would the connection be allowed?
FWIW, if we were to do this, I think pg_hba.conf would be a fine place for this. That's where you currently have configuration for what happens when a client with certain host/username/database tries to connect. In addition to "accept" or "reject", it seems logical to add "redirect" as an outcome, instead of e.g. adding a whole new configuration file fore this.
But overall, IMHO we should mark this patch "rejected". - Heikki
