Hello,
However, there might be a packaging issue.
I expect SCRAM to become the main way to authenticate, so it would be nice if pgjdbc could just work with no need to add different jars to the classpath.
The question is how should we deal with the dependency.
1) We could make it optional & dynamic. That is we refrain from including the client to pgjdbc artifacts. In case backend is configured for SASL, pgjdbc would bail out with "please add scram-client-whatever.jar to the classpath" error.
The drawback is pgjdbc would require a certain versions of scram-client, so it might cause troubles in future if application code and pgjdbc would require different incompatible versions of the client.
2) We could incorporate scram-client to the pgjdbc artifacts, so it would just work if backend requests SASL. This option enables us to repackage the client with our own name (e.g. org.postgresql.ongress.scram...), so it will enable applications to use scram-clients of their choice.
I'm inclined to #2 (incorporate scram-client at build time), however I am not sure if it will ripple via some packaging issues.
Note: I expect we might want to add new dependencies later (e.g. for "SASL string preparation", or Netty for networking layer), so it would be nice to know limits/edge packaging cases.
Vladimir
