分类：
2008-05-07 22:49:29
|
PostgreSQL 应用手册 文章出处: The PostgreSQL Development Team Edited by Thomas Lockhart PostgreSQLis Copyright ?1996-2000 by PostgreSQL Inc. 编译：何伟平 laser@zhengmai.com.cn 第一章 PostgreSQL的起源和历史，我们在这里就不再介绍了,请参考我们网站的PostgreSQL数据库应用（一） PostgreSQL可免费获得。本手册的描述是基于PostgreSQL 7.0版本。 注：现在最新版本是PostgreSQL 8.1.4 Released 下载官方网站： Postgres可以移植到任何有完全libc库支持的Unix/Posix－兼容的系统上。 Red Hat的Fedora Core和Mandriva都预装有PostgreSQL数据库。 ------------------------------------------------ **资源** ------------------------------------------------ ▓ 本手册由以下几部分组成： ● 教程 给新用户的介绍，不包括高级特性。 ● 用户手册 用户需要了解的常用信息，包括可用的命令和类型。 ● 程序员手册 应用程序员需要的高级信息，包括类型和函数扩展，库接口以及应用设计方面的内容。 ● 管理员手册 安装和管理信息，所支持的平台的列表。 ● 开发人员手册 Postgres 开发者所需的信息．这部分内容是给那些有志于参与Postgres项目开发的人员看的；应用开发的信息应该包括在程序员手册内，这部分内容包含在程序员手册中。 ● 参考手册 命令语法的详细参考信息，当前包含在用户手册中。 除了上述手册外，其他的一些资源也可以帮助你安装和使用Postgres： ● 手册页 手册页包含常用信息和命令语法 FAQs 常问的问题（FAQ）文档包含常见问题和平台相关问题的解答 READMEs 一些贡献的包包含README文件． ● 站点 Postgres 网站有一些在发布版里没有的信息．在网站上有一个mhonarc邮件列表的目录，通常是解决问题的很好的地方。 ● 邮件列表 pgsql-general（归档）邮件列表是解决用户问题的好地方；同时还有其他的邮件列表，详见PostgreSQL网站的Info Central部分。 Postgres是一个开放源码的东西，也就是说，它靠用户群体进行支持工作。当你刚开始使用Postgres时，你将依靠其他人的帮助，或者是通过文档，或者是通过邮件列表。同时请也将你的知识贡献出来，如果你学到了一些文档里没有提到的东西，请将其写下来并贡献出来。如果你给代码增加了特性，请贡献出来。 甚至没有很多经验的人也可以提供文档的修正和小修改，这就是好的开始。pgsql-docs（归档）邮件列表就是开始的地方。 ------------------------------------------------ **术语** ------------------------------------------------ 在下面的文档中，节点(?site) 可以理解为安装Postgres的机器。由于我们可以在一台机器上安装多套Postgres数据库，所以，准确地说这个词代表所安装的某一套Postgres的二进制文件和数据库的集合。 Postgres超级用户是叫postgres的用户，他拥有Postgres的二进制文件和数据库文件。作为数据库超级用户，他拥有超越所有保护机制和访问任何数据的特权。另外，Postgres超级用户可以执行一些并非所有用户可以执行的程序。要注意的是Postgres超级用户和Unix超级用户（通常叫做root）并不相同。出于安全的原因数据库的超级用户应该有一个非零的用户标识（UID）。 数据库管理员或称之为DBA，负责安装Postgres和制定这个数据库的安全策略。DBA可以用下面描述的方法增加用户和维护一套用于createdb的模板库。 postmaster是充当发往Postgres系统的请求的净化间的进程。前端应用与postmaster相连，由它监控任何系统错误和与后端进程的通讯。postmaster可由一些命令行参数来调节其特性。不过，只有你试图同时运行多套数据库或某一套非缺省的数据库时才需要设置参数。 Postgres的后端进程（实际上是可执行文件postgres）可由Postgres超级用户直接在命令行上运行（以数据库名为参数）。不过，这样做绕过了与postmaster/节点（site）相连的共享缓冲池和锁表，因而不推荐在一个多用户节点上这么做。 -------------------------------------------------------------------------------- 符号 -------------------------------------------------------------------------------- “...”或在文件名前面的/usr/local/pgsql/用于代表Postgres超级用户的家目录。 在命令行参数里，方括号（“[” 和 “]”）表示一个可选词或关键字。任何用花括号（“{” 和 “}”）括起来的包含竖直条（“|”）的内容表示你必须选择一个。 在例子里，圆括号 （“(”和“)”）用于组合布尔表达式。“|”是布尔计符"或"（OR）． 例子将演示从不同用户和程序执行命令的结果。root用户执行的命令将由“>”开头。Postgres超级用户执行的命令将由“%”开头，普通用户执行的命令由“$”开头。SQL 命令视情况由“=>”开头或没有前导字符。 ▓ 问题汇报指导 当你在PostgreSQL里碰到问题时，我们也希望听到它。你的臭虫汇报是将PostgreSQL做得更加可靠的一个非常重要的部分，因为即使是细致到极限的工作也不能保证在任何情况任何平台下PostgreSQL的每一个部分都能正常工作。 下面的建议试图帮助你正确格式化臭虫报告，这样这些报告就能够以一种有效的方法处理。我们不强迫任何人遵循这些东西，但是这样做对我们每个人都有好处。 我们不能保证能够正确修补每个臭虫。如果臭虫是显而易见的，很关键的或者影响许多用户，那么很有可能有些人会认真检查它们。同样也可能是我们告诉你升级到一个新版本，看看臭虫是否仍然存在。否则，我们可能会说这个臭虫在我们正计划的几个主要改写之前不会得到修补。或者这个臭虫只是太费事了，而且目前的日程表上有更重要的事情要做。如果你立即需要帮助，考虑获取一个商业性的支持。 ● 标识臭虫 在你发出“这是个臭虫吗？”这样的问题之前，请一再仔细地读文档，以确认你确实可以做你想做的事情。如果文档中对你能否处理你所做的事情并不清楚，也请你汇报过来；因为这个是文档的臭虫。如果发现你的程序的表现不象文档里说的那样，那就是一个臭虫。这时可能包括（不过不一定局限于）下面的现象： 程序带着一个致命信号或者一个指向程序错误的操作系统错误信息（一个反例是一个“disk full”（磁盘满）信息，因为这样的错误必须在Postgres外部进行修复）退出。 程序对给出的任何输入都产生错误的输出。 程序拒绝接收有效的输入。 程序对非法输入没有生成任何提示或者错误信息。 在支持的平台上根据指导未能成功地编译、制作或安装PostgreSQL。 这里的“程序”代表任何可执行文件，而不仅仅是后端服务器。 速度慢或者资源消耗大不算是臭虫。请阅读文档或者提交邮件列表之一获取调节你的应用（的性能）的帮助。未能遵循SQL也不算是一个臭虫，除非显式声明了遵守该特定特性。 在你继续准备汇报臭虫之前，请检查TODO列表和FAQ，看看你报告的臭虫是否已知。如果你不能解析TODO列表里面的信息，请汇报你的问题。最少我们可以把TODO列表做得更清晰。 ● 汇报什么 关于汇报臭虫需要记住的最重要事就是写出所有事实并且只写事实。不要推测你认为是什么错了，什么"看起来象"，或者是推测程序的哪一部分失灵了。如果你不熟悉Postgres的实现，你很可能猜错因而不能帮我们任何忙。而且即使你熟悉Postgres的实现，提炼出来的解释也只是事实的补充而不是代替。如果我们准备修理这个臭虫，我们仍然需要首先亲自看到臭虫的出现。报告简单的事实相对而言比较直接（你可以从屏幕上拷贝和粘贴），不过经常发生的是很多人认为这些事实不重要而忽略了重要的细节，否则汇报总是能够被我们理解。 ● 下面的条目应该包含在所有臭虫汇报里面： 从程序启动开始到重现问题的准确步骤顺序。这应该自包含；要知道如果输出将依赖于表中的数据时，光把一个光秃秃的select语句发过来而不吧前面的创建表和插入语句发过来是不够的。我们没有时间分析你的数据库结构，而且如果我们试着建立我们自己的数据，那我们就有可能错过问题。测试与查询语言有关的问题的最好的格式是一个可以通过psql前端运行并显示问题的文件。（确保在你的~/-psqlrc启动文件里面没有任何东西。）我们鼓励你最小化你的例子，但这不是非做不可的事情。如果臭虫是可以复现的，那么两种方式都能帮助我们找到它。 如果你的应用使用其他客户端接口，比如说 PHP，那么请设法隔离出有毛病的查询。我们可能不会设置一个web服务器来复现你的问题。不管怎么说，请记住提供准确的输入文件，而不要猜测问题会在“大文件”或者“中等尺寸的数据库”等等的身上发生。因为这样的信息太不确切，因而没有什么用处。 你得到的输出。请不要说它"不起作用"或者"失灵了"。如果有错误信息，请写明，即使你不能理解也一样。如果程序带着操作系统错误退出，也请写清楚。如果什么也没有发生，就照直说。即使你的测试实例是程序崩溃或者其他显而易见的现象，它也有可能不会在我们的平台上发生。如果可能，最简单的事情是从终端拷贝输出。 注意： 如果是致命错误，客户端提供的信息可能不会包含所有能得到的信息。这种情况下，还要看看数据库服务器的输出。如果你没有保留你的服务器输出，那么现在是做这件事的好机会。 还有一样很重要去声明的是你期望的输出。如果你只是写到“这条命令给我这样的输出。”或者“这不是我期望的。”，我们可能自己运行它，检查输出，然后认为看上去很好并且正是我们所期望的输出。我们不应该把时间花在解析你的命令的语义上。特别是要避免仅仅说“这不是SQL说的/Oracle做的那样。”从SQL里挖掘出正确的特性可不是好玩的事情，我们也不能知道所有其他的关系数据库的特性是怎样的。（如果你的问题是程序崩溃，你显然可以忽略这个条目。） 任何命令行选项和其他启动选项，包括相关的环境变量或者你从缺省值修改以后的配置文件。同时，还要准确。如果你使用启动系统时自动启动数据库服务器的预打包的版本，你应该试着找出这些是怎样实现的。 ● 任何你做得与安装指导不一样的东西。 PostgreSQL版本。你可以运行命令SELECT version( )；来检查你正在运行的版本是什么。如果这个函数不存在，请说明，这样我们就知道你的版本有多老。如果你无法启动服务器或者客户端，参阅源码目录里面的README文件或者看看你的发布文件的名称或包名称。如果你的版本早于7.0，我们几乎可能会告诉你去升级。每个新版本都会有成吨的臭虫被修理掉，这也是我们写（新版本）的原因。 如果你运行预打包的版本，例如RPM，请说明，包括那个包可能有的任何子版本号。如果你说的是CVS快照，说明之，包括它的日期和时间。 平台信息。这包括内核名称和版本，C库，处理器，存储器信息。大多数情况下只需要汇报供应商和版本，但是不要指望每个人都很清楚“Debian”包括什么东西或者说每个人都运行在Pentium上。如果你还有关于编译器，make等安装的问题信息，也有必要详细汇报。 不要怕你的臭虫汇报变得很长。这就是生活。一开始就汇报所有的事情要比让我们从你那里挤出事实要好。另外，如果你的输入文件非常巨大，先问问有没有人有兴趣查看它也是合理的。 不要把你的时间花在寻找如何通过修改输入来消除问题的方法上。这样很有可能不能对解决问题有任何帮助。如果发现不能直接修理臭虫，你还有时间来查找和共享你的绕过方法。还有，我们再说一便，不要在猜测臭虫的位置上面浪费时间。我们能够及时找到错误。 当你书写臭虫汇报时，请选用不易混淆的术语。软件包本身被称为"PostgreSQL"，有时称为 "Postgres"。（有些时候用缩写“Pgsql”，但是请不要这么使用。）当你特指后端服务器时，请明确说明，而不要仅仅是说“Postgres崩溃了”。交互前端（SQL界面）叫做“psql”而且在所有用法和用途上都是和后端完全分离的。 ● 到哪里汇报臭虫 通常，把汇报发到臭虫汇报邮件列表。我们建议你为你的电子邮件消息选用一个描述性的题目，也许就用错误信息的一部分。 不要把臭虫汇报发送到任何用户邮件列表里，例如SQL语言邮件列表或通用话题邮件列表。这些邮件列表用于回答用户问题，而且那些订阅者通常不希望接收臭虫汇报。更重要的是，他们很可能不会修理这些臭虫。 还有，请不要向开发者邮件列表发送臭虫汇报。这个列表用于讨论PostgreSQL的开发，因而我们很希望能和臭虫汇报分离开。如果修理这个臭虫需要更多评论，我们可能会在这个列表开一个关于你的臭虫的讨论会。 如果你觉得文档有问题，请发电子邮件到文档邮件列表。在你的问题汇报里面指明文档、章、节。 如果你的臭虫是一个在不支持平台上的移植性问题，向移植性问题邮件列表发送电子邮件，这样我们（还有你）可以一起尝试把PostgreSQL移植到你的平台上。 注意： 由于我们不愿意看到的各种各样的垃圾邮件，上面的所有电子邮件地址都是封闭的邮件地址。也就是说，你需要先申请，然后才能发帖子。如果你只是想发送邮件而不想接受列表的往来的邮件，你可以提交特殊的pgsql-loophole邮件列表，那里允许你向所有PostgreSQL邮件列表发信而接收不到任何信息。向pgsql-loophole-request@postgresql.org发邮件来申请。 （译注：这里用“assume”这个词真多，让我想起一个老外给我讲解“assume”的意思："ass-u-me" ass=屁股。。。哈哈。。。） ============================================= ▓ Y2K 声明 作者：Thomas Lockhart于1998-10-22。更新于2000-03-31。 PostgreSQL 全球开发队伍将提供Postgres软件的代码树作为一种公众服务，对其特性和性能不做任何保证和承诺，但是，到我们写这些为止： 这些声明的作者，作为一个从1996年11月开始从事Postgres支持的志愿者，并未发现任何 Postgres的代码与2000年1月1日的时间切换(Y2K)相关。 本声明的作者并未收到当前或最近版本的Postgres任何与Y2K问题相关的报告，不论是在做递归测试还是在其他领域的使用中。考虑到我们的装机量和我们的邮件列表的活跃性，如果问题存在，我们应该可以获得消息。 据作者所知，Postgres对两位数年份的一些假设的文档在用户手册中的日期类型章节中。就两位数年份而言，关键的切换年份1970年，而不是2000年；比如"70-01-01"被看作是 1970-01-01，而"69-01-01"将被看作是2069-01-01。 任何因OS取"当前时间"造成的Y2K问题都可能传染到Postgres。 请参考Gnu工程和Perl大学进一步讨论Y2K问题，尤其是开放源码（免费）软件。  |
| 出处：南方Linux |
