我们试图解决三个问题。

1. 我们不想受限于服务器发布计划。之前版本基于服务器版本来声明某种兼容性，从 9.4.xxxx 开始，这种情况不再存在，增量只在最后 4 位数字上，这导致了第二个问题。
2. 避免混淆使用哪个版本与哪个服务器版本。之前的命名方案中包含 9.4，这让人们误以为它只适用于服务器版本 9.4，而实际上它支持 PostgreSQL 8.2 及更高版本。这意味着一些寻找 PostgreSQL 9.5 的用户会问应该使用哪个版本，而一些仍然使用 PostgreSQL 8.4 的用户则使用 JDBC 驱动程序 8.4 Build 703。驱动程序在大多数情况下与版本无关，因此没有理由将其绑定到特定服务器版本。除非您有特殊要求（运行旧应用程序或 JVM），否则您应该使用此驱动程序。
3. 之前的版本策略没有空间区分错误修复版本和功能版本。

新的版本策略将允许我们更多或更少地使用语义版本控制，并对版本有更清晰的理解。

42 是一个随机选择的数字，但它足够大，可以避免将来与服务器发生冲突。根据当前的服务器项目策略，服务器版本 42 应该在 2049 年发布，可能会有所偏差。有人说，“生命、宇宙和一切的终极答案是 42”。

这个版本不是对驱动程序的重写，也不使用新的架构，也不使用任何特殊的东西，它只是遵循更好的版本控制策略的同一驱动程序的延续。

是的，从 8.1dev-403 驱动程序开始。但是，不支持事务交错。

事务交错意味着一个数据库连接可以同时用于多个事务，并在事务之间切换。事务交错基本上没有用，但它是 JTA 规范的必要部分。一些应用程序服务器使用它来允许更多的并发性，而无需分配更大的 JDBC 连接池。很少有 JDBC 驱动程序正确地支持事务交错。有些通过发出早期准备命令来伪造它，这会冒着事务完整性的风险，有些会给出奇怪的错误消息，有些会在其他微妙的方式中失败。PostgreSQL JDBC 驱动程序尽力检测交错并在无法执行请求的操作时抛出适当的错误消息。由于缺乏驱动程序支持，所有流行的应用程序服务器都提供了绕过它的选项，或者根本不使用它。因此，缺乏事务交错不会影响您的应用程序或数据完整性。有关更多信息，请参阅 JTA 规范第 3.4.4 节，或搜索 pgsql-jdbc 邮件列表存档。

这与批处理查询和同步 TCP 相关。要查看的是将网络缓冲区大小设置为较大的值以避免死锁。默认值是机器相关的，这也解释了它在不同机器上是否工作（感谢 Kris Jurka）。