PostgreSQL基础知识( 六 )


外部数据源的数据 。只要数据映射关系配置正确,外部表的用法就与普
通表没有任何区别 。外部表支持映射到以下类型的数据源:CSV 文件、
另一个服务器上的 PostgreSQL 表、SQL Server 或 Oracle 这些异构数据
库中的表、Redis 这样的 NoSQL 数据库,甚至像 Twitter 或 Salesforce
这样的 Web 服务 。
外部表映射关系的建立是通过配置外部数据封装器(foreign
data
wrApper,FDW)实现的 。FDW 是 PostgreSQL 和外部数据源之间的一
架“魔法桥”,可实现两边数据的互联互通 。其内部实现机制遵循
SQL
标准中的 MED(Management of External Data)规范,更多细节请参考
维基百科上关于 MED 的描述 。
许多无私的开发者已经为当下大部分流行的数据源开发了 FDW 并
已免费共享出来 。你也可以通过创建自己的 FDW 来练习 。(我们建议
你一旦成功了也公布出来,这样整个社区都可以分享你的劳动成果 。)
FDW 是通过扩展包机制实现的,安装好以后在 pgAdmin 界面上名为
Foreign Data Wrapper 的目录节点下能看到它 。
触发器和触发器函数
绝大多数企业级数据库都支持触发器机制,该机制可以侦测到数据
修改事件的发生 。在 PostgreSQL 中,当一个触发器被触发后,系统会
自动调用用户定义好的触发器函数 。触发器的触发时机是可设置的,可
以是语句级触发或者记录级触发,也可以是修改前触发或修改后触发 。在 pgAdmin 中,如果希望了解哪些表上挂载了触发器,只需在对
象树上层层点击,一直打开到表这一级,然后可以看到下面有个 trigger
子栏目,里面就是该表的所有触发器 。
定义触发器时需要定义对应的触发器函数,这类函数与前面介绍过
的普通函数有所不同,主要差异在于触发器函数可以通过系统内置变量
来同时访问到修改前和修改后的数据,这样就可以实现对于非法的数据
修改行为的识别和拦截 。因此触发器函数一般会用于编写复杂校验逻
辑,这类复杂逻辑通过 check 约束是无法实现的 。
PostgreSQL 的触发器技术正在快速的演进之中 。9.0 版引入了对
WITH 子句的支持,通过它可以实现带条件的记录级触发,即只有当某
条记录符合指定的 WHEN 条件时,触发器才会被调用 。9.0 版还引入了
UPDATE OF 子句,通过它可以实现精确到字段级的触发条件设置 。仅当
指定的字段内容被更改时才会激活触发器 。9.1 版支持了针对视图的触
发器 。9.3 版支持了针对 DDL 的触发器 。目前支持触发器的 DDL 命令
列表请参见官方手册中“触发器触发时机一览表” 。pgAdmin
中会把
DDL 触发器列在 event trigger 这一栏下 。最后值得一提的是,从 9.4 版
开始,针对外部表的触发器也获得了支持 。
catalog
catalog 的译法与 schema 存在相同的问题,翻译为“目录”后并不能让读者准确地理解其原意,
反而容易造成混淆,因此还是沿用英文原名 。——译者注
catalog 是系统级的 schema,用于存储系统函数和系统元数据 。每

database
创建好以后默认都会含有两个
catalog:一个名为
pg_catalog,用于存储 PostgreSQL 系统自带的函数、表、系统视图、
数据类型转换器以及数据类型定义等元数据;另一个是
information_schema,用于存储 ANSI 标准中所要求提供的元数据查
4
4询视图,这些视图遵从 ANSI SQL 标准的要求,以指定的格式向外界提
供 PostgreSQL 元数据信息 。
一直以来,PostgreSQL 数据库的发展都严格地遵循着其“自由与开
放”的核心理念 。如果你足够了解这款数据库,会发现它几乎是一种可
以“自我生长”的数据库 。比如,它所有的核心设置都保存在系统表中,
用户可以不受限地查看和修改这些数据,这为 PostgreSQL 提供了远超
任何一种商业数据库的巨大灵活性(不过从另一个角度看,将这种灵活
性称为“可破坏性”也未尝不可) 。只要仔细地研究一下 pg_catalog,
你就可以了解到 PostgreSQL 这样一个庞大的系统是如何基于各种部件
构建起来的 。如果你有超级用户权限,那么可以直接修改 pg_catalog
的内容(当然,如果改得不对,那你的行为就跟搞破坏没什么两样
了) 。
Information_schema catalog 在 MySQL 和 SQL Server 中也有 。
PostgreSQL 的 Information_schema 中最常用的视图一般有以下几


推荐阅读