背景

通读一遍PG的官方文档，也许是一件有趣的事情，不妨当作一种补充的学习方法。它的特点在于它的内容的全面并且具有权威姓。缺点就是可能一些技术细节不会具体到您想要的程度。

试图按照文档的顺序重新进行压缩式整理，把重要的内容提炼出来，与大家分享。

PG文档之前言

1、什么是PostgreSQL

postgresql是一个基于POSTGRES 4.2版本的对象关系数据库管理系统(ORDBMS)，由加州大学伯克利分校计算机科学系开发。POSTGRES开创了许多概念，这些概念直到很久以后才出现在一些商业数据库系统中。

PostgreSQL是原始Berkeley代码的开源后代。它支持大部分SQL标准，并提供许多现代特性:

• 复杂的查询

• 外键

• 触发器

• 可更新视图

• 事务完整性

• 多版本并发控制

此外，PostgreSQL可以通过许多方式被用户扩展，例如通过添加新的

• 数据类型

• 函数

• 运算符（操作符）

• 聚合函数

• 索引方法

• 过程语言

由于自由许可证，任何人都可以出于任何目的免费使用、修改和发布PostgreSQL，无论是私人的、商业的还是学术的。

2、PostgreSQL简要发展历史

现在被称为PostgreSQL的对象-关系数据库管理系统是从加利福尼亚大学伯克利分校编写的POSTGRES包派生出来的。经过20多年的发展，PostgreSQL现在是世界上最先进的开源数据库。

2.1、Berkeley 的POSTGRES项目

POSTGRES项目由Michael Stonebraker教授领导，由国防高级研究计划局(DARPA)、陆军研究办公室(ARO)、国家科学基金会(NSF)和ESL公司赞助。POSTGRES的实现始于1986年。系统的初始概念在[ston86]中提出，初始数据模型的定义在[rowe87]中给出。当时规则系统的设计在[ston87a]中有描述。存储管理器的基本原理和体系结构详见[ston87b]。

从那时起，POSTGRES经历了几个主要版本。第一个“演示”系统在1987年开始运行，并在1988年ACM-SIGMOD会议上展示。版本1，在[ston90a]中描述，于1989年6月发布给一些外部用户。作为对第一个规则系统的批评([ston89])的回应，规则系统被重新设计([ston90b])，并在1990年6月发布了带有新规则系统的版本2。版本3出现于1991年，增加了对多个存储管理器的支持、改进的查询执行器和重写的规则系统。在很大程度上，直到Postgres95(见下文)的后续版本都专注于可移植性和可靠性。

POSTGRES已被用于实现许多不同的研究和生产应用程序。这些系统包括:一个金融数据分析系统、一个喷气发动机性能监测包、一个小行星跟踪数据库、一个医疗信息数据库和几个地理信息系统。POSTGRES也被一些大学用作教学工具。最后，Illustra Information Technologies(后来并入Informix，现在归IBM所有)获得了代码并将其商业化。1992年末，POSTGRES成为Sequoia 2000科学计算项目的主要数据管理器。

1993年期间，外部用户社区的规模几乎翻了一番。越来越明显的是，原型代码的维护和支持占用了大量本应用于数据库研究的时间。为了减轻这种支持负担，Berkeley POSTGRES项目在4.2版正式结束。

2.2、Postgres95

1994年，Andrew Yu和Jolly Chen为POSTGRES添加了一个SQL语言解释器。在一个新的名字下，Postgres95随后发布到网络上，作为原始POSTGRES Berkeley代码的开源后代，在世界上找到了自己的道路。

Postgres95的代码完全是ANSI C语言，并且缩减了25%的大小。许多内部更改改进了性能和可维护性。Postgres95 1.0版本。与POSTGRES 4.2版本相比，1.0.x版本在威斯康星基准测试上的运行速度提高了30-50%。除了bug修复之外，以下是主要的增强:

• 查询语言PostQUEL被SQL(在服务器中实现)所取代。(接口库libpq是以PostQUEL命名的。)直到PostgreSQL才支持子查询(见下文)，但在Postgres95中可以通过用户定义的SQL函数来模仿子查询。重新实现了聚合函数。还添加了对GROUP BY查询子句的支持。

• 提供了一个用于交互式SQL查询的新程序(psql)，它使用GNU Readline。这在很大程度上取代了旧的监视器程序。

• 一个新的前端库libpgtcl支持基于tcl的客户机。一个示例shell pgtclsh提供了新的Tcl命令来将Tcl程序与Postgres95服务器连接起来。

• 对大对象接口进行了彻底修改。反转(inversion)大对象是存储大对象的唯一机制。(反转文件系统已被删除。)

• 删除了实例级规则系统。规则仍然可以作为重写规则使用。

• 一个介绍常规SQL特性以及Postgres95特性的简短教程随源代码一起发布

• 构建使用了GNU make(而不是BSD make)。此外，Postgres95可以使用未打补丁的GCC进行编译(修复了双精度的数据对齐)。

2.3、PostgreSQL

到1996年，很明显“Postgres95”这个名字经不起时间的考验。我们选择了一个新名字，PostgreSQL，以反映最初的POSTGRES和具有SQL功能的最新版本之间的关系。同时，我们将版本号设置为从6.0开始，将数字放回到最初由Berkeley POSTGRES项目开始的序列中。

许多人继续将PostgreSQL称为“Postgres”(现在很少全部大写)，因为传统或因为它更容易发音。这种用法被广泛接受为昵称或别名。

开发Postgres95的重点是识别和理解服务器代码中存在的问题。对于PostgreSQL，重点已经转移到增强特性和功能上，尽管所有领域的工作仍在继续。

关于PostgreSQL从那时起发生的变化的细节可以在附录E中找到。

3、约定

以下约定用于命令摘要:括号([和])表示可选部分。大括号({和})和竖线(|)表示您必须选择一个选项。点(…)表示前面的元素可以重复。所有其他符号，包括括号，应按字面意思理解。

在增强清晰度的地方，SQL命令前面有提示符=>，shell命令前面有提示符$。但是，通常不会显示提示符。

管理员通常是负责安装和运行服务器的人。用户可以是任何正在使用或想要使用PostgreSQL系统的任何部分的人。这些术语的解释不应过于狭隘;本书没有关于系统管理过程的固定假设。

4、进一步的信息

除了文档，也就是这本书，还有其他关于PostgreSQL的资源:

维基
PostgreSQL wiki(https://wiki.postgresql.org/)包含项目的FAQ(常见问题)(https://wiki.postgresql.org/wiki/Frequently_Asked_Questions)列表，TODO列表(https://wiki.postgresql.org/wiki/Todo)，以及更多主题的详细信息。

网站
PostgreSQL网站提供了最新版本的详细信息和其他信息，使您的工作或使用PostgreSQL更有效率。

邮件列表
邮件列表是回答您的问题、与其他用户分享经验以及与开发人员联系的好地方。有关详细信息，请参阅PostgreSQL网站。

您自己!
PostgreSQL是一个开源项目。因此，它依赖于用户社区的持续支持。当您开始使用PostgreSQL时，您将依赖其他人的帮助，或者通过文档，或者通过邮件列表。考虑回馈您的知识。阅读邮件列表并回答问题。如果您学到了文档中没有的东西，把它写下来并贡献出来。如果您向代码中添加了特性，请贡献它们。

5、BUG报告使用指南

当您在PostgreSQL中发现一个bug时，我们希望听到您的反馈。您的错误报告在使PostgreSQL更加可靠方面起着重要的作用，因为即使是最谨慎的也不能保证PostgreSQL的每个部分在任何情况下都能在每个平台上工作。

以下建议旨在帮助您形成可以以有效方式处理的bug报告。没有人被要求遵循它们，但这样做往往对每个人都有利。

我们不能保证马上修复每一个bug。如果这个bug很明显、很严重，或者影响到很多用户，那么很有可能有人会去调查它。它也可能发生，我们告诉您更新到一个较新的版本，看看是否有错误发生。或者我们可能会决定在我们可能计划的一些主要重写完成之前无法修复该错误。又或者，这实在是太难了，日程上还有更重要的事情要做。如果您需要立即获得帮助，请考虑获取商业支持合同。

5.1、确定BUG

在你报告一个bug之前，请反复阅读文档来确认你真的可以做你想做的事情。如果从文件中看不清楚你是否可以做某事，也请报告;这是文档中的一个错误。如果一个程序所做的事情与文档所说的不同，那就是一个bug。这可能包括但不限于以下情况:

• 程序以致命信号或操作系统错误消息结束，这将指向程序中的问题。(一个反例可能是“磁盘已满”消息，因为您必须自己修复它。)

• 程序对任何给定的输入都产生错误的输出。

• 程序拒绝接受有效输入(如文档中所定义)。

• 程序接受无效输入而不发出通知或错误消息。但请记住，您对无效输入的想法可能是我们对传统实践的扩展或兼容性的想法。

• PostgreSQL在支持的平台上无法按照说明编译、构建或安装。

这里的“程序”指的是任何可执行程序，而不仅仅是后端进程。

速度慢或占用资源不一定是bug。阅读文档或在邮件列表中寻求调优应用程序的帮助。不符合SQL标准也不一定是bug，除非明确声明符合特定的特性。

在继续之前，请查看TODO列表和FAQ，看看您的bug是否已经被发现。如果您无法解码TODO列表中的信息，请报告您的问题。我们至少可以把待办事项清单弄清楚。

5.2、报告什么内容

关于bug报告，要记住的最重要的事情是陈述所有事实，并且只陈述事实。不要猜测你认为哪里出了问题，“它似乎在做什么”，或者程序的哪一部分有问题。如果您不熟悉实现，您可能会猜错，而不是帮助我们一点。即使你是，受过教育的解释是对事实的一个很好的补充，但不能代替事实。如果我们要修复这个bug，我们仍然必须首先亲眼看到它发生。报告简单的事实相对简单(你可能可以从屏幕上复制粘贴)，但通常重要的细节都被遗漏了，因为有人认为这无关紧要，或者报告无论如何都会被理解。

每个bug报告中都应该包含以下内容:

• 从程序启动到重现问题所必需的步骤的确切顺序。这应该是独立的;如果输出应该依赖于表中的数据，那么仅仅发送一条没有前面的CREATE TABLE和INSERT语句的SELECT语句是不够的。我们没有时间对您的数据库模式进行逆向工程，而且如果我们应该自己编写数据，我们可能会错过问题。

sql相关问题的测试用例的最佳格式是可以通过显示问题的psql前端运行的文件。不要在你的口袋里放任何东西。PSQLRC启动文件)        创建该文件的一种简单方法是使用pg_dump转储设置场景所需的表声明和数据，然后添加问题查询。我们鼓励您尽量减少示例的大        小，但这不是绝对必要的。如果这个bug是可复制的，我们无论如何都会找到它。

如果您的应用程序使用其他客户端接口，比如PHP，那么请尝试隔离不合适的查询。我们可能不会设置web服务器来重现您的问题。       在任何情况下，记得提供准确的输入文件;不要猜测问题发生在“大文件”或“中型数据库”等，因为这些信息太不准确而无法使用。

• 你得到的输出。请不要说它“不起作用”或“崩溃”。如果有错误消息，即使您不理解它，也要显示它。如果程序因操作系统错误而终止，说明是哪个。如果什么都没发生，就这么说。即使测试用例的结果是程序崩溃或其他明显的问题，它也可能不会在我们的平台上发生。如果可能的话，最简单的方法是从终端复制输出。

  注意：

  如果您正在报告错误消息，请获取消息的最详细形式。在psql中，事先说\set VERBOSITY verbose。如果要从服务器日志中提取消息，请将运行时参数log_error_verbosity设置为verbose，以便记录所有详细信息。

  在致命错误的情况下，客户端报告的错误消息可能不包含所有可用的信息。还请查看数据库服务器的日志输出。如果您没有保留服务器的日志输出，那么现在是开始这样做的好时机。

• 说明您期望的输出非常重要。如果你只写“这个命令给我那个输出。或“这不是我所期望的。”，我们可能会自己运行它，扫描输出，并认为它看起来不错，正是我们所期望的。我们不应该花时间去解码你的命令背后的确切语义。特别是不要仅仅说“这不是SQL说的/Oracle做的”。从SQL中挖掘出正确的行为并不是一件有趣的事情，我们也不知道所有其他关系数据库的行为。(如果您的问题是程序崩溃，那么显然可以省略这一项。)

• 任何命令行选项和其他启动选项，包括从默认值更改的任何相关环境变量或配置文件。请再次提供准确的信息。如果您使用的是在引导时启动数据库服务器的预打包发行版，那么您应该尝试找出如何做到这一点。

• 您所做的任何与安装说明不同的事情。

• PostgreSQL版本。可以运行命令SELECT version(); 以查找所连接的服务器的版本。大多数可执行程序也支持——version选项; 至少postgres——version和PSQL——version应该可以工作。如果功能或选项不存在，则说明您的版本太旧，需要进行升级。如果您运行一个预打包的版本，比如rpm，那么请这样说，包括包可能具有的任何subversion。如果您谈论的是Git快照，请提及它，包括提交散列。

  如果你的版本比15.2早，我们几乎肯定会告诉你升级。在每个新版本中都有许多错误修复和改进，所以很有可能你在旧版本中遇到的错误已经被修复了。我们只能对使用旧版本PostgreSQL的站点提供有限的支持;如果您的需求超出了我们的能力，请考虑获得商业支持合同。

• 平台信息。这包括内核名称和版本、C库、处理器、内存信息等等。在大多数情况下，报告供应商和版本就足够了，但不要假设每个人都确切地知道“Debian”包含什么，或者每个人都在x86_64上运行。如果您有安装问题，那么关于机器上的工具链(编译器、make等)的信息也是必要的。

如果您的bug报告变得相当冗长，不要担心。这是生活的事实。最好是第一时间就把一切都报告出来，而不是我们从你嘴里逼出事实。另一方面，如果您的输入文件很大，那么首先询问别人是否有兴趣查看它是公平的。这里有一篇文章概述了报告bug的更多技巧。

不要把你所有的时间都花在弄清楚输入中的哪些变化会使问题消失。这可能无助于解决问题。如果事实证明错误不能立即修复，您仍然有时间找到并分享您的解决方法。同样，不要浪费时间猜测bug存在的原因。我们很快就会知道的。

在编写bug报告时，请避免混淆术语。整个软件包称为“PostgreSQL”，有时简称为“Postgres”。如果你是专门谈论后端进程，提到这一点，不要只是说“PostgreSQL崩溃了”。单个后端进程的崩溃与父进程postgres的崩溃是完全不同的;当您的意思是单个后端进程崩溃时，请不要说“服务器崩溃”，反之亦然。此外，客户端程序(如交互式前端“psql”)与后端完全分离。请尽量具体说明问题是在客户端还是在服务器端。

5.3、到哪里报告BUG

通常，将bug报告发送到bug报告邮件列表pgsql-bugs@lists.postgresql.org。您被要求为您的电子邮件使用一个描述性的主题，也许是错误消息的一部分。

另一种方法是填写项目网站上提供的bug报告web表单。以这种方式输入错误报告将导致它被发送到pgsql-bugs@lists.postgresql.org邮件列表。

如果您的错误报告涉及安全问题，并且您不希望它在公共存档中立即可见，请不要将其发送到pgsql-bugs。安全问题可以私下报告到security@postgresql.org。

不要将bug报告发送到任何用户邮件列表，例如pgsql-sql@lists.postgresql.org或pgsql-general@lists.postgresql.org。这些邮件列表是用来回答用户问题的，它们的订阅者通常不希望收到错误报告。更重要的是，他们不太可能解决这些问题。

此外，请不要将报告发送到开发人员的邮件列表pgsql-hackers@lists.postgresql.org。这个列表是用来讨论PostgreSQL的开发的，如果我们能把bug报告分开就好了。如果问题需要更多的审查，我们可能会选择对您关于pgsql-hackers的错误报告进行讨论。

如果您对文档有问题，最好的报告地点是文档邮件列表pgsql-docs@lists.postgresql.org。请具体说明您对文档的哪一部分不满意。

如果你的错误是一个不受支持的平台上的可移植性问题，请发送邮件到pgsql-hackers@lists.postgresql.org，这样我们(和你)就可以将PostgreSQL移植到你的平台上。

注意：

由于垃圾邮件的数量庞大，所有上述列表将被缓和，除非你订阅。这意味着在邮件发送之前会有一些延迟。如果您想订阅这些列表，请访问https://lists.postgresql.org/获取说明。