PostgreSQL架构的命名空间版本是为了向后兼容？

Question

假设我们有一个带有表Person的SQL数据库和几个访问它的应用程序。出于某种原因，我们希望以向后不兼容的方式修改Person表。

保持兼容性的一个可能解决方案是将表重命名为User并创建一个Person视图，该视图提供与旧表相同的接口。 （根据需要在插入上添加，在更新上添加，在删除触发器上添加）。

该方法存在的问题是，经过一些更改后，我们可能会用尽可用的语义正确的名称。

根据数据库版本，是否有一个众所周知的“命名空间”模式“接口”的最佳实践？

或者，是否有更好的方法来保持向后兼容性？

Answer 1

  

根据数据库版本，是否有一个众所周知的“命名空间”模式“接口”的最佳实践？

这不是一个常见的要求，但是当我看到需要类似的东西时，我倾向于创建一个新的模式，其中包含一个单独的模式（命名空间）中的表的向后兼容的包装器。然后我按用户设置search_path，以便需要后向compat表的用户看到它，其他人看到新版本。

BC视图有RULE或（在较新的PostgreSQL版本中）DO INSTEAD触发器，从其正常模式明确引用表的当前版本，例如{ {1}}，以便在需要时支持写入。

这仅适用于您需要基于每个登录用户的BC，public.People或（不太可能）您可以设置需要BC运行ALTER USER ... SET search_path命令的应用程序的情况每次会议。