第 1 章 基礎知識

PostgreSQL 是一款極其強大的數據庫，它的很多特性可能是你前所未見

的。它的部分特性在其他知名數據庫中也有，但名稱可能不同。在深入

鑽研官方手冊之前，你需要了解一些核心概念，本章將為你介紹這些概

念，期間也會涉及其他數據庫中的相關概念和術語。

本章將首先介紹如何下載和安裝 PostgreSQL，然後會介紹一些必備的管

理工具和 PostgreSQL 術語。本書寫作之時，PostgreSQL 10 已發佈，我

們將重點介紹該版本的一些新特性。本章末尾會提供一些幫助資源，當

你需要額外的幫助或者報告 bug 時會用得到。

1.1 為什麼應該選擇PostgreSQL

PostgreSQL是一款企業級關係型數據庫管理系統，即使與 Oracle、

Microsoft SQL Server、IBM DB2 等業界最好的商用數據庫相比也毫不

遜色。PostgreSQL 之所以如此特別，是因為它不僅僅是一個數據庫，還

是一個功能強大的應用開發平臺。

PostgreSQL 的速度很快。大量的評測數據已經表明：與其商用以及開源

競爭對手相比，PostgreSQL 的速度要麼遠遠勝出，要麼旗鼓相當。

PostgreSQL 支持用多種編程語言編寫存儲過程和函數。除了系統自帶的

C、SQL 和 PL/ pgSQL 編程語言外，還可以通過安裝擴展包來支持

PL/Perl、PL/Python、PL/V8（又稱為 PL/JavaScript）、PL/Ruby 以及

PL/R 等。這種支持多語言的能力可以讓開發人員根據待解決問題的特

點來選擇最合適的語言。比如可以使用 R 語言來解決統計和圖形領域的

問題，通過 Python 來調用 Web 服務，通過使用 SciPy 庫來進行科學計

算，通過 PL/V8 來進行數據驗證、字符串處理和 JSON 數據處理，等

等。PostgreSQL 不但支持種類繁多的開發語言，使用過程也很簡單：先

找到你需要的函數，看下它是用什麼語言編寫的，在 PostgreSQL 中安

裝好支持該語言的擴展包，然後把代碼複製過來就可以執行了。真的不

能更簡單。

大多數數據庫會限制用戶只能使用預定義的數據類型，比如整型、字符

串、文本型、布爾型等。PostgreSQL 在數據類型的支持方面有兩個優

勢：不但支持比絕大多數數據庫更豐富的原生數據類型，而且還允許用

戶按需自定義數據類型。如果用戶需要更復雜的數字類型，那麼可以定

義包含兩個浮點類型（float）的複合類型；如果需要定義一個三角形，

那麼可以先定義一種“座標”類型，然後再定義一種包含三個座標的“三角形”

類型即可；

如果你對十二進制感興趣，那麼可以定義你自己的十二進制類型。值得注

意的是，要想自定義類型完全發揮出其威力，需要有相應的運算符和函數

來識別並配合它。因此，如果你自定義了一種特殊的數值類型，千萬不要

忘了為它重定義配套的數學運算符。是的，你沒看錯，PostgreSQL 允許用

戶重定義基礎運算符（+、-、/、*）的實現邏輯。另外，用戶自定義一種數

據類型後，PostgreSQL 會自動定義出一種基於該類型的數組類型。因此，

如果你定義了一種複合數據類型，那麼該複合數據類型的數組類型自動就有

了，你無須做額外的定義工作。

PostgreSQL 會為每一張用戶表自動創建一個數據類型定義。比如我們創

建了一張名為 dogs 的表，包含 breed（品種）、cuteness（可愛程

度）、barkiness（愛叫的程度）等字段，那麼 PostgreSQL 會自動在後臺

創建一個同名的dogs數據類型。這一特性將關係型數據庫領域

的“表”概念與面向對象領域的“對象”概念緊密地聯繫到了一起，用戶可

以像處理對象實例一樣去處理記錄。比如你可以創建一個函數來每次處

理一個或者一批對象實例。PostgreSQL 的很多第三方擴展包就利用該自

定義數據類型能力來優化性能，或者通過添加支持某個領域專用的特殊

SQL 語法來讓業務代碼更簡潔和易於維護，或者實現一些在別的數據庫

中完全不可能實現的功能。

我們建議用戶不要把數據庫僅僅當成一個數據容器，像 PostgreSQL 這

樣的數據庫其實是一個成熟而完整的應用開發平臺。你會發現：強大的

數據庫在手，其他一切都是過眼雲煙。一旦你成了 SQL 高手，別人用

其他工具需要幾小時才能完成的工作，你在數據庫裡只需要幾秒鐘。不

管是對比編碼時間還是對比實際數據處理時間，效果都是如此。

近年來，我們看到很多 NoSQL 數據庫異軍突起，一時風頭無兩（我們

認為這裡面有很大的炒作成分）。儘管 PostgreSQL 總體上看是一個關係

型數據庫，但它其實也具備強大的處理非關係型數據的能力。比如

ltree 這個插件可以處理圖數據，但我們幾乎已經想不起它到底是何時被

加入到 PostgreSQL 中的；又比如 hstore 插件可以實現鍵值存儲；還有

JSON 和 JSONB 類型可以提供類似 MongoDB 的文檔操作能力。從很多

方面來看，PostgreSQL 甚至在“NoSQL”這個詞出現之前就已經提供了那

些所謂的 NoSQL 特性。

如果從 Postgres95 正式改名為 PostgreSQL 開始算起，PostgreSQL 已經

誕生二十年了，但事實上它的歷史可向前一直追溯到

1986年。 PostgreSQL 支持當前所有主流的操作系統，包括 Linux、Unix、

Windows 以及 Mac。目前每年會發佈一個大版本，包含性能提升以及那

些不斷超越關係型數據庫功能極限的新功能。

從 1986 年開始，Stonebraker 教授發表了一系列論文，引入對象關係理念，

探討了新的數據庫的結構設計和擴展設計。1988 年，他發表了 Postgres 的

第一個原型設計，

1989 年 6 月發佈了版本

1。因此 1986 年可視為 PostgreSQL 發展史的元年。——譯者注

最後值得一提的是，PostgreSQL 不但是開源的，而且開源得非常徹底，

它的許可策略非常寬鬆。現在 PostgreSQL 社區由一群無私奉獻的的開

發者和用戶構成，他們並不把賺錢視為人生終極目標。如果需要新特

性，你可以自行貢獻代碼或者提出訴求。如果你試圖修改 PostgreSQL

代碼以為己所用，也不會有人起訴你。是成千上萬用戶的參與和貢獻使

得 PostgreSQL 變成了它今日的模樣。

到最後你會想：我為什麼還要使用別家的數據庫？PostgreSQL 已經提供

了我所需要的一切功能，而且還是免費的！你不再需要去閱讀那些商業

數據庫附帶的密密麻麻的授權條款，來了解在一個八核虛擬機上支持 X

個併發連接所需要的費用是多少，也不需要了解每次升級後要再為許可

證加多少錢。

1

11.2 不適用PostgreSQL的場景

在為 PostgreSQL 做了這麼多“鼓吹”之後，我們也應介紹一下它不適用

於哪些場景。

在不安裝任何擴展包的情況下，PostgreSQL 需佔用 100MB 以上的磁盤

空間，可以看出它的個頭還是比較大的。因此，在一些存儲空間極為有

限的小型設備上使用 PostgreSQL 是不合適的，把 PostgreSQL 當成簡單

的緩存區來用也是不合適的，此時應選用一些更輕量級的數據庫。

作為一款企業級數據庫產品，PostgreSQL 對於安全是極其重視的。因

此，如果你在開發一個把安全管理放到應用層去做的輕量級應用，那麼

PostgreSQL 完善的安全機制反倒會成為負擔，因為它的角色和權限管理

非常複雜，會帶來不必要的管理複雜度和性能損耗。此時可以考慮選用

SQLite 這樣的單用戶數據庫，或者選用 FireBird 這樣既能以客戶端 / 服

務器模式運行也能以嵌入式單用戶模式運行的數據庫。

通過上述介紹可以看到，一般來說需要將 PostgreSQL 與別的數據庫搭

配使用，使它們各展所長。一種常見的組合是把 Redis 或者 Memcache

當成 PostgreSQL 的查詢緩存來用；另一種組合是用 PostgreSQL 做主數

據庫，用 SQLite 存儲離線數據來做離線查詢。

令人遺憾的一個事實是，很多共享主機服務（多個用戶共享同一個操作

系統實例）供應商並不支持預安裝 PostgreSQL，或者只支持安裝一個很

陳舊的版本。它們更喜歡預裝較弱的 MySQL。對於一個 Web 設計人員

來說，用什麼數據庫並不是首要問題，此時 MySQL 可能能夠滿足要

求。但當用戶的 SQL 技能不斷提升，不再滿足於寫一寫單表 select 或者

簡單的 join 查詢時，MySQL 的缺點就會暴露無遺。自本書第一版出版

以來，虛擬化技術的進步使得商業化的雲主機服務得到了長足的發展，因此

擁有自己的獨立雲主機不再是一件很奢侈的事情。當用戶擁有自己

的獨立雲主機時，就可以自由選擇在上面安裝什麼軟件。隨著

PaaS（平臺即服務）、DBaaS（數據庫即服務）等雲計算模式的流行，

PostgreSQL的發展前景向好。絕大多數的雲服務廠商都提供

PostgreSQL 服務，其中比較著名的有 Heroku、Engine Yard、RedHat

OpenShift、Amazon RDS for PostgreSQL、Google Cloud SQL for

PostgreSQL、Amazon Aurora for PostgreSQL 以及 Microsoft Azure for

PostgreSQL。

1.3 如何獲得PostgreSQL

若干年前，你只能通過手動編譯源碼的方式來安裝 PostgreSQL。還好那

種痛苦的時代已經一去不復返了。當然，現在依然可以通過編譯源碼來

安裝，但大多數用戶會使用製作好的安裝包來安裝，只需敲擊幾下鍵盤

和鼠標就可以了。

如果你是首次安裝 PostgreSQL，那麼應該選擇適用於你的操作系統平臺

的最新穩定版發行包。PostgreSQL 官方站點的核心發佈頁面上維護了一

個列表，記錄了適用於各操作系統的二進制包的下載地址。在附錄

A

中，你會看到安裝指導和一些定製版本的下載鏈接地址。

1.4 管理工具

PostgreSQL 常用的管理工具有四種：psql、pgAdmin、phpPgAdmin 和

Adminer。PostgreSQL 的核心開發團隊維護著前三種，因此它們一般會

隨著 PostgreSQL 的版本發佈而同步更新。Adminer 並非 PostgreSQL 的

專用管理工具，它支持管理多種類型的關係型數據庫，包括 SQLite、

MySQL、SQL Server 和 Oracle。除了剛剛提到的這四種以外，還有大量

優秀的管理工具，開源的和商業的都有。

1.4.1 psql

psql 是一種用於執行查詢的命令行工具，每個 PostgreSQL 發行版中都

自帶 psql（參見附錄 B.4 節）。它有一些獨特的功能，比如導入和導出

基於分隔符（逗號或者製表符等）格式的平面數據文件，以及生成簡易

的 HTML 格式報表等。psql 是 PostgreSQL 從誕生之初就一直附帶的命

令行工具，它是很多高級用戶日常操作工具的不二之選，非常適用於只

有控制檯字符界面而無圖形用戶界面的使用場景。另外，在通過 shell

腳本執行數據庫操作時，psql 也是必備工具。不過新用戶一般更喜歡使

用圖形界面工具，而且也無法理解為什麼“老”一代人會對命令行方式那

麼執著。

1.4.2 pgAdmin

pgAdmin 是一款流行的免費的 PostgreSQL 圖形界面管理工具。如果你

的 PostgreSQL 安裝包裡沒有附帶此工具，請從其官網單獨下載安裝。

pgAdmin 可在 PostgreSQL 支持的任意一種操作系統平臺上運行。

即使你的數據庫安裝在只有控制檯字符界面的 Linux 服務器上，只要你

在本地工作站上安裝了 pgAdmin，也可以用這種強大的圖形化工具對其進行管理。

pgAdmin 近期已經發布了它的第四個大版本，稱為 pgAdmin4。該版本

對之前的 pgAdmin3 進行了徹底的重寫，使用 Python 實現了“一套代碼

兩種模式運行”的效果，一種模式是作為桌面應用運行，另一種是在瀏

覽器中運行。pgAdmin4 當前的版本是 1.5。pgAdmin4 的首個版本是與

PostgreSQL 9.6 同時發佈的，並被若干 PostgreSQL 發行版作為自帶軟件

一起打包發佈。如前所述，pgAdmin4 既可以作為桌面應用運行，也可

以在瀏覽器中運行。

圖 1-1 是 pgAdmin4 的界面示意圖。圖 1-1：pgAdmin4 的樹狀視圖

如果你對 PostgreSQL 還不太熟悉，那麼 pgAdmin 毫無疑問是你開始

PostgreSQL 學習之旅的最佳入口。只需在主界面上摸索一下，你就可以

對 PostgreSQL 的豐富功能一覽無遺。如果你正打算逃離 Microsoft SQL

Server 陣營，並且習慣於 SQL Server 的 Management Studio，那麼很快

就能適應 pgAdmin。

相比 pgAdmin3，pgAdmin4 還有一些短板，但它正在快速補齊並在很多

方面都超過了 pgAdmin3。即便如此，如果你是 PgAdmin3 的長期用戶

並且短期內無法切換到 pgAdmin4，那麼你可以繼續使用 BigSQL 公司

提供的 pgAdmin3 LTS（長期支持）版，在對 pgAdmin4 進行完善測試

後再切換過去。請務必牢記，pgAdmin4 才是 pgAdmin 未來的主力版

本，pgAdmin3 只會維持現狀，不會再有什麼發展。

1.4.3 phpPgAdmin

phpPgAdmin 是一種免費的基於 Web 頁面的管理工具，其界面如圖 1-2

所示。它是從流行的 MySQL 管理工具 phpMyAdmin 移植而來的，二者

的差別主要在於 phpPgAdmin 新增了對 PostgreSQL 的 schema、過程式

語言、類型轉換器、運算符等對象的管理功能。如果你對 phpMyAdmin

很熟悉，會發現 phpPgAdmin 的界面風格與其完全類似。圖 1-2：phpPgAdmin

1.4.4 Adminer

如果你正在尋找一款除了能夠管理 PostgreSQL，還能管理別的數據庫的

整合型工具，那麼 Adminer 將是你合適的選擇。Adminer 是一款輕量級

的開源 PHP 應用程序，可以在同一套圖形界面上管理 PostgreSQL、

MySQL、SQLite、SQL Server 以及 Oracle 等多種數據庫。

Adminer 有一種獨特的功能讓我們印象深刻：它能夠以圖形化方式展示

數據庫中的對象，並將外鍵約束關係以連接線的方式展示出來。另外，

整個 Adminer 程序的本體僅包含一個 PHP 文件，非常簡潔，這可以大

大減少你安裝部署時的麻煩。

圖 1-3 中，左側是登錄屏幕的截圖，右側是表間關係圖形化後呈現的效

果。很多用戶會因為登錄屏幕上沒有填寫端口號的地方而感到困惑。如

果 PostgreSQL 使用標準的 5432 偵聽端口，那麼登錄時不填也沒問題；

但如果不是，就需要在服務器名稱後面加上端口號，注意用冒號分隔主

機名和端口號，如圖 1-3 所示。圖 1-3：Adminer

對於簡單的查詢和修改操作來說，Adminer 的功能是足夠的。但為了支

持多種數據庫，Adminer 的功能體系已經被裁剪成了各數據庫均支持的

最小公共集合，因此你無法實現 PostgreSQL 所特有的一些操作，比如

創建新用戶、授予權限、查詢當前權限列表等。Adminer 為了與它所支

持的各家數據庫在概念上保持兼容和通用而將每個 schema 當作一個

database，這使得以圖形化展示表與表之間外鍵關係這一功能受到了極

大影響，如果兩個不同 schema 的表之間存在外鍵關聯關係，那麼在

Adminer 的界面上是無法展示出來的。如果你是 DBA，那麼建議使用

pgAdmin，當然也可以安裝一套 Adminer 以備不時之需。1.5 PostgreSQL數據庫對象

假設你現在已經安裝好了 PostgreSQL，請啟動並連接好 pgAdmin，然後

點開左側的目錄樹，此時展現在你面前的是一堆令人眼花繚亂的數據庫

對象，有些你可能很熟悉，有些則可能聞所未聞。PostgreSQL 對象類型

的數量超過了絕大多數關係型數據庫（這還是在未安裝任何擴展包的情

況下）。這些對象中，有許多你可能永遠都不會用到，但如果你發現業

務上需要實現一種新的對象類型，那麼一般來說你要實現的東西在那一

堆眼花繚亂的對象中已經有前人實現過了，所以只需要正確選用即可。

本書不會介紹 PostgreSQL 以標準方式安裝完畢後所提供的所有對象類

型，因為 PostgreSQL 引入新特性的速度驚人，任何一本書都不可能全

面覆蓋所有對象類型。因此我們僅討論你有必要了解的那些對象類型。

database2

2database 一詞含義寬泛，既可表示廣義的數據庫系統，又可以表示某些特定數據庫系統中的

某一級數據存儲單位，如表述不當極易給讀者造成混淆。因此本書中會區別使用，表示廣義的

數據庫系統時，用中文“數據庫”；表示狹義的數據存儲單位時，用英文“database”。——譯者

注

每個 PostgreSQL 服務可以包含多個獨立的 database。

schema3

3數據庫業界對於 schema 有多種譯法：綱要、模式、方案，等等。但各種譯法都不能準確直觀

地表達出其原本的含義，即位於一個獨立命名空間內的一組相關數據庫對象的集合，因此前述

譯法從來沒有一種成為主流。一般業界人員都直接使用英文 schema。考慮到這個情況，為防

止初級用戶理解困難，我們也按照業界習慣直接使用英文原名。——譯者注

ANSI SQL 標準中對 schema 有著明確的定義，database 的下一層邏

輯結構就是 schema。如果把 database 比作一個國家，那麼 schema 就是一些獨立的州

（或者是省、府、轄區等，具體取決於各國的實際情況）。大多數對象

是隸屬於某個 schema 的，然後 schema 又隸屬於某個 database。在創建

一個新的 database 時，PostgreSQL 會自動為其創建一個名為 public 的

schema。如果未設置

search_path

變量（後續會介紹該變量的含

義），那麼 PostgreSQL 會將你創建的所有對象默認放入 public schema

中。如果表的數量較少，這是沒問題的，但如果你有幾千張表，那麼我

們還是建議你將它們分門別類放入不同的 schema 中。

表

任何一個數據庫中，表都是最核心的對象類型。在

PostgreSQL

中，表首先屬於某個 schema，而 schema 又屬於某個 database，這樣就

構成了一種三級存儲結構。

PostgreSQL 的表支持兩種很強大的功能。第一種是表繼承，即一張

表可以有父表和子表。這種層次化的結構可以極大地簡化數據庫設計，

還可以為你省掉大量的重複查詢代碼。第二種是創建一張表的同時，系

統會自動為此表創建一種對應的自定義數據類型。

視圖

大多數關係型數據庫都支持視圖。視圖是基於表的一種抽象，通過

它可以實現一次性查詢多張表，也可以實現通過複雜運算來構造出虛擬

字段。視圖一般是隻讀的，但 PostgreSQL 支持對視圖數據進行修改，

前提是該視圖基於單張實體表構建。如果需要修改基於多張表關聯而來

的視圖，可以針對視圖編寫觸發器。9.3

版還引入了對物化視圖的支

持，該機制通過對視圖數據進行緩存來實現對常用查詢的加速，缺點是

查到的數據可能不是最新的。更多細節請參見 7.1.3 節。擴展包

開發人員可以通過該機制將一組相關的函數、數據類型、數據類型

轉換器、用戶自定義索引、表以及屬性變量等對象打包成一個功能擴展

包，該擴展包可以整體安裝和刪除。擴展包在概念上與

Oracle

的

package 類似，從 PostgreSQL 9.1 版本之後一般推薦使用該機制來為數

據庫提供功能擴展。擴展包的具體安裝步驟，請參考開發手冊。一般來

說，需要先將擴展包的二進制安裝包和腳本複製到 PostgreSQL 安裝目

錄下，然後運行一系列腳本，再在需要其功能的 database 中單獨安裝該

擴展包。注意：僅需在需要該擴展包功能的 database 中安裝，不必為當

前數據庫系統中的每個 database 都安裝。比如需要對某個 database 中的

數據進行高級文本搜索，那麼單獨在該

database

中安裝

fuzzystrmatch 擴展包即可。

安裝擴展包時可以指定該包中所含有的成員對象安裝到哪個

schema，若不指定則默認會安裝到 public schema 中。我們不建議採用

默認設置，因為這會導致 public schema 變得龐大複雜且難以管理，尤

其是如果你將自己的數據庫對象也都存入 public schema 中，那麼情況

會變得更糟糕。我們建議你創建一個獨立的 schema 用於存放所有擴展

包的對象，甚至為規模較大的擴展包單獨創建一個 schema。為避免出

現找不到新增擴展包對象的問題，請將這些新增的 schema 名稱加入

search_path 變量中，這樣就可以直接使用擴展包的功能而無須關注

它到底安裝到了哪個 schema 中。也有一些擴展包明確要求必須安裝到

某個 schema 下（特別是過程式語言擴展包），這種情況下你就不能自

行指定了。有很多語言擴展包，比如

plv8，就要求必須安裝到

pg_catalog schema 中。

多個擴展包之間可能存在依賴關係。在 PostgreSQL 9.6 之前，你需

要了解這個依賴關係並把被依賴包先裝好，但從 9.6 版開始，只需在安裝時加上 cascade 關鍵字，PostgreSQL 就會自動安裝當前擴展包所依

賴的擴展包。例如：

CREATE EXTENSION postgis_tiger_geocoder CASCADE;

這條命令會先尋找並安裝被依賴的 postgis 和 fuzzystrmatch 這

兩個擴展包，當然，如果原本就有了，就不需要了。

函數

用戶可以編寫自定義函數來對數據進行新增、修改、刪除和複雜計

算等操作，可以使用 PostgreSQL 所支持的各種過程式語言來編碼。

PostgreSQL

裝好以後自身就包含了數以千計的系統函數，都在默認的

postgres

庫中。函數支持返回以下數據類型：標量值（也就是單個

值）、數組、單條記錄以及記錄集。其他數據庫將對數據進行增刪改操

作的函數稱為“存儲過程”，把不進行增刪改的函數叫作“函數”，但

PostgreSQL 中並不區分，統一把二者稱為“函數”。

內置編程語言

函數是以過程式語言編寫的。PostgreSQL 默認支持三種內置編程語

言：SQL、PL/pgSQL 以及 C 語言。可以通過 CREATE EXTENSION 或者

CREATE PRODCEDURAL LANGUAGE 命令來添加其他語言。目前較常用的

語言是 PL/Python、PL/V8（即 JavaScript）以及 PL/R。我們將在第 8 章

中展示大量的相關示例。

運算符

運算符本質上是以簡單符號形式呈現的函數別名，例如 =、&& 等。

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 中最常用的視圖一般有以下幾

個：columns 視圖，列出了數據庫中的所有字段； tables 視圖，列出

了數據庫中的所有表（包括視圖）；views 視圖，列出了所有視圖以及

用於創建該視圖的原始 SQL。

類型

類型是數據類型的簡稱。每種數據庫產品和每種編程語言都會支持

一系列的數據類型，比如整型、字符型、數組、二進制大對象（blob）

等。除前述常見類型外，PostgreSQL 還支持複合數據類型，這種類型可

以是多種數據類型的一個組合，比如複數、極座標、向量、張量等都是

複合數據類型。

PostgreSQL 會自動為用戶自己創建的表定義一個同名的複合數據類

型。這樣就可以把表記錄當作對象實例來處理。當用戶需要在函數中遍歷表記錄時，該特性特別注意：在 pgAdmin 的界面上你看不到

這些在創建表時自動生成的自定義類型，但請放心，這並不代表它們不

存在。

全文檢索

全文檢索（full text search，FTS）是一種基於自然語言的搜索機

制。這種搜索機制有一些“智能”成分。與正則表達式搜索不同，全文檢

索能夠基於語義來進行匹配查找，而不僅僅是純粹的語法匹配。例如，

用戶需要在一段長文本中搜索 running 這個詞，那麼命中的結果可能包

含 run、running、jog、sprint、dash 等詞。全文檢索功能依賴於 FTS 配

置庫、FTS 詞典、FTS 解析器這三個部件。有了它們，PostgreSQL 原生

的 FTS 功能即可正常使用。一般場景下的全文檢索靠這三個原生部件

已經足夠，但在涉及藥理學、有組織犯罪學等專業場景下，搜索目標文

本中會包括該領域專有詞彙和特殊語法規則，此時需要用專門的

FTS

部件來替換原生 FTS 部件。我們會在 5.8 節探討 FTS 功能。

數據類型轉換器

數據類型轉換器可以將一種數據類型轉換為另一種，其底層通過調

用轉換函數來實現真正的轉換邏輯。PostgreSQL 支持用戶自定義轉換器

或者重載、加強默認的轉換器。例如，如果你需要把郵政編碼（美國的

郵政編碼是一個 5 位的整數）從 integer 轉換為 character，那麼可

以自定義一個支持“數字不足 5 位則前面自動補 0”規則的轉換器。

轉換器可以被隱式調用也可以被顯式調用。隱式轉換是系統自動執

行的，一般來說，將一種特定數據類型轉為更通用的數據類型（比如數

字轉換為字符串）時就會發生隱式類型轉換。如果進行隱式轉換時系統

找不到合適的轉換器，你就必須顯式執行轉換動作。序列號生成器

序列號生成器用於實現 serial 數據類型值的自動遞增分配。在創

建 serial 字段時，PostgreSQL 會自動為其創建一個相應的序列號生成

器，但用戶也可以很方便地更改其初始值、步長和下一個值。因為序列

號生成器是獨立對象，所以多個表可以共享同一個序列號生成器。基於

該機制，用戶可以實現跨越多個表的唯一鍵。SQL Server 和 Oracle 也都

支持序列號生成器，但必須手動創建。

規則

規則的功能是在一個 SQL 執行前對其進行改寫。本書中不會討論

有關規則的內容，因為這一技術已經過時，通過觸發器能實現相同的功

能。

PostgreSQL 允許用戶對前述每一種對象進行參數配置。這些參數可以在

服務級、庫級、函數級等不同層級生效。你將來很可能會看到一個很炫

的詞叫 GUC，意思是“大一統配置”（grand unified configuration），它

實際上指的就是 PostgreSQL 中的那些配置參數。1.6 最新版本的PostgreSQL中引入的新特性

PostgreSQL 在每年的 9 月份會發佈一個大版本。每個新版本都會帶來穩

定性、安全性、性能等方面的提升，以及一些前沿的新特性。而且版本

升級過程也變得越來越簡單。那麼顯而易見，請儘量把你的數據庫及時

升級到最新的穩定版。關於每個版本引入的關鍵特性列表，請參見官方

提供的“PostgreSQL 各版本功能特性一覽表”。

1.6.1 為什麼要升級

如果你正在使用 PostgreSQL 9.1 或者更早的版本，請立即升級！因為

9.1 版在 2016 年 9 月已進入生命週期終結（end of life，EOL）狀態。請

參考 PostgreSQL 官方的發行版支持策略以獲取更多關於 PostgreSQL

EOL 政策的細節。請務必不要使用已過了 EOL 期限的版本，因為開發

組不會再為其提供新的安全更新和功能補丁。一旦這種老版本出了問

題，你只能花錢去請 PostgreSQL 專家級顧問來解決故障或尋找臨時解

決方案，這種服務一般都是很昂貴的，而且你不一定能找得到這種專

家。

不管當前使用的是哪個大版本，你都應該儘快跟進小版本號的更新。比

如從 9.1.17 升級到 9.1.21，只需要替換二進制文件並重啟一下即可。小

版本僅修改 bug 而不會涉及功能變化，因此這種升級是很安全的，也會

為你降低出問題的概率。

1.6.2 PostgreSQL 10中引入的新特性

PostgreSQL 10 是目前最新的穩定版，於 2017 年 10 月發佈。從

PostgreSQL 10 開始，PostgreSQL 會以一種新的方式升級其版本號。在

之前的版本中，發佈大版本時變化的是第二位小版本號，比如從PostgreSQL 9.5 到 PostgreSQL 9.6，即使增加了一些比較大的新功能，

也只有小版本號發生變化。但從 PostgreSQL 10 開始，每個變化較大的

版本都會在主版本號上加一。因此 PostgreSQL 10 的下一個大版本是

PostgreSQL 11。這樣就與 SQLite、SQL Server、Oracle 等數據庫的版本

號策略保持了一致。

以下是 PostgreSQL 10 中引入的關鍵新特性。

提升了查詢的並行度

對於並行查詢啟用了新的優化策略，包括並行位圖堆掃描、並行索

引掃描等。這些增強將使得更多查詢語句能被並行執行。請參考 9.4 節

邏輯複製

此前版本的 PostgreSQL 中已經支持流複製特性。通過流複製可以

實現整個 PostgreSQL 服務實例的複製，但該機制有一些固有的缺點：

從節點是隻讀的，只能用於數據查詢，不能對其數據進行修改；從節點

上也不能創建自己獨有的表。邏輯複製解決了這兩個問題。通過邏輯復

制可以實現僅複製單張表或者單個 database（不用複製整個服務實例的

所有數據）。既然不需要複製整個數據庫服務，那麼自然從庫上就可以

有自己的表和數據，這部分數據是不包含在複製體系中的，因此主從庫

上允許不一樣。

針對 JSON 和 JSONB 類型的全文檢索

此前的版本中，to_tsvector 函數僅能為文本類型的字段生成全

文檢索向量。現在它已支持處理 JSON 和 JSONB 類型，處理過程中會

忽略其中 key 的部分，而僅包含 value 的部分。同時 ts_headline 函數

也專為 JSON 和 JSONB 類型做了適配，它可以對 JSON 內容中的關鍵字進行加亮標記。詳情請參考 5.8.7 節。

支持

XMLTABLE 特性可以將 XML 文本內容以一種更為簡單的方式映射

為普通二維表記錄。該特性在 Oracle 和 IBM DB2 中已支持。詳情請參

見示例 5-41。

FDW 聚合下推

FDW API 可以將 COUNT(*) 或者 SUM(*) 這種聚合操作推送到遠端

節點執行。postgres_fdw

插件從該特性中受益最大。此前的版本

中，postgres_fdw 插件在執行聚合操作時，需要把所有相關數據從遠

端 PostgreSQL 取到本地然後再進行聚合運算，這極大地影響了整體運

算效率。

此前的版本中，實現分區表功能需要藉助表繼承機制。表繼承機制

的問題在於，用戶需要自行編寫觸發器來實現把數據分流到子表中的過

程。PostgreSQL 10 引入了 PARTITION BY 語法，利用該語法，用戶只

需在創建表時附加 PARTITION BY 子句就可以自動實現表分區。此後向

父表插入數據時，數據會被分流到子表中，這一切都是自動的，無須用

戶預先創建觸發器。請參考 6.1.3 節以瞭解詳情。

查詢性能優化

該版本中對查詢性能實現了多方面的優化。

支持創建多字段統計信息CREATE STATISTICS 命令支持針對多個字段建立統計信息。具體

請參見示例 9-18。

支持 IDENTITY 數據類型

新增支持 IDENTITY 自增字段類型，創建表和修改表結構時都可以

使用。增加該類型是為了在設計表的自增字段時更加符合業界通行做

法。具體請參見示例 6-2。

PostgreSQL 9.6 發佈於 2016 年 9 月，是 9.x 系列中的最新版本。

支持並行查詢

9.6 版之前，PostgreSQL 並不能充分地利用系統中的多核能力。9.6

版中，PostgreSQL 引擎能夠將一些特定類型的查詢語句放到多個處理器

核心上並行執行。支持並行執行的操作有：順序掃描、部分 join 以及部

分聚合操作。然而，增刪改這些修改數據的操作無法實現並行。支持並

行化的工作還在進行中，最終目標是所有的語句都能利用到多核並行執

行。詳情參見 9.4 節。

支持關聯詞組全文檢索

全文檢索支持關聯詞組搜索，可以使用 運算符來表示兩個關聯

詞之間的距離。即使關聯詞沒有連在一起出現，只要二者出現的位置不

超出前述距離，也認為該關聯詞組搜索命中。在 9.6 之前的版本中，只

能搜索一些單個的詞，但該功能使得用戶可以搜索一組有前後順序的詞

組。詳情請參見 5.8 節。

psql 工具支持 \\gexec 參數該參數的功能是讀取並執行一個根據查詢語句動態生成的 SQL。詳

情請參見 3.4.5 節。

postgres_fdw 增強

對於簡單的更新、插入和刪除來說，速度有很大提升。請參考博

文“Directly Modify Foreign Tables”以瞭解詳情。

FDW 關聯操作下推

包括 postgres_fdw 在內的部分 FDW 已支持該特性。當需要對多

張外表做關聯查詢時，之前的做法是把每張外表的數據取回本地然後做

關聯計算，支持了該特性的 FDW 的優化處理方式是：如果需要關聯的

兩張外表都來自於同一臺外部服務器，那麼就把 join 操作下推到這個外

部服務器上去執行，然後僅把關聯結果拿回來。這樣可以極大地減少經

網絡傳輸的記錄數。當關聯操作可以過濾掉大量數據時，這個特性帶來

的性能提升是巨大的。

1.6.4 PostgreSQL 9.5中引入的新特性

PostgreSQL 9.5 發佈於 2016 年 1 月，其主要的新特性如下。

外部表架構的改進

支持了新的 IMPORT FOREIGN SCHEMA 命令，通過該命令可以從外

部服務器中加載表結構信息從而實現批量創建外表。支持外表繼承：本

地表可以繼承自外表，外表也可以繼承自本地表，外表也可以繼承自另

一張外表。支持在外表上創建約束。詳情請參見 10.3 節和 10.3.3 節。

支持無日誌表直接升級為日誌表由於無日誌表不寫日誌，往其中導入數據時會很快，但缺點是數據

庫崩潰時會完全丟失數據。在此前的版本中，當數據完全導入無日誌表

後，要想把無日誌表改為日誌表需要創建一張新表，然後再把無日誌表

的數據寫入新表。9.5 版提供了一個新的語法：ALTER TABLE ... SET

UNLOGGED，可以直接把無日誌表修改為日誌表，這樣就省去了重新建

表並搬遷數據的過程。

array_agg 函數支持數組入參

array_agg 函數可以將某字段的多條記錄聚合為一個數組。在 9.5

版之前，入參字段類型不能是一個數組，但 9.5 版之後支持輸入數組入

參，這樣就可以構造出多維數組。詳情請參見示例 5-17。

支持 BRIN 索引類型

BRIN（block range index）是一種新型的索引，相比 B-樹和 GIN 索

引有著更小的內存佔用。有些情況下 BRIN 索引會比前述兩種索引速度

更快。詳情請參見 6.3 節。

支持 GROUPING SETS、ROLLUP 和 CUBE 聚合語法

該特性用於聚合查詢語句中，可以實現一次性獲取多維度匯聚結

果。具體例子請參見 7.7 節。

僅索引掃描

如果要查詢的字段在索引中已經全部包含，則僅掃描索引即可獲得

查詢結果，而不用訪問表數據，這種查詢模式稱為“僅索引掃描”。當前

只有 GiST 索引支持此特性。

支持“無則插入有則更新”處理（即 UPSERT 能力）9.5

版之前，如果插入或者更新操作違反了主鍵約束或者其他約

束，那麼該操作會失敗。9.5 版提供了一種機制，允許用戶捕獲該異常

並自定義替代操作或者跳過引發問題的記錄。詳情請參見 7.2.11 節。

支持跳過無法寫鎖定的記錄

如果用戶希望鎖定一些記錄以用於後續更新，那麼可以使用

SELECT ... FOR UPDATE 來鎖定這些記錄。在 9.5 版之前，如果試圖

鎖定的部分或者全部記錄已被其他用戶鎖定，那麼當前用戶的鎖定操作

就會報錯。9.5 版中提供了一個 SKIP LOCKED 子句語法，可以跳過那些

已經被別人鎖定的記錄，這樣就不會報錯。

行級安全控制

支持對用戶設置記錄級的讀寫權限，即同一張表中，部分記錄只允

許某個用戶讀寫，另外一部分記錄只允許另外一個用戶讀寫。在多租戶

場景下，顯然該功能是特別有用的；對於需要進行訪問權限隔離而又無

法通過分表實現的場景，該功能也特別有價值。

1.6.5 PostgreSQL 9.4中引入的新特性

9.4 版發佈於 2014 年 9 月，主要包含以下新特性。

物化視圖特性的改進

在 9.3 版中，刷新物化視圖期間會對其加鎖並禁止訪問，而加鎖時

間可能會比較長，這直接導致在生產環境中物化視圖的實用價值嚴重受

限。9.4 版中取消了刷新時的加鎖動作，因此即使是正在被刷新的物化

視圖也可被訪問。但請注意：利用此特性的前提是物化視圖必須擁有一

個唯一索引。新增支持用於計算百分比的分析函數

新增了對

percentile_disc（不連續百分比）和

percentile_cont（連續百分比）這兩個分析函數的支持，須配合

WITHIN GROUP (ORDER BY...) 子句使用。PostgreSQL 專家 Hubert

Lubaczewski 在文章“Ordered Set Within Group Aggregates”中介紹了

ORDERED SET WITHIN GROUP 聚合運算。在 9.5 之前的版本中，

PostgreSQL 並未提供過計算中位數的函數。這是有原因的。如果你對計

算中位數的相關算法有所瞭解的話，應該知道這種算法中最後都會有一

個額外的類似於“平局加時賽”的計算步驟，這個步驟的存在使得將中位

數算法實現為聚合函數非常困難。9.5 版中引入的這兩個分析函數使用

了一種快速中位數估算算法，從而繞開了前述問題。我們將在 7.2.16 節

對這兩個函數進行更深入的介紹。

支持對視圖更新操作的結果範圍進行限制

創建視圖時支持 WITH CHECK OPTION 子句，其作用是確保在視圖

上執行更新或者插入操作時，修改後或者新插入的記錄仍然在本視圖可

見範圍內。詳情請參見示例 7-3。

新增對 JSONB 數據類型的支持

該數據類型是 JSON（JavaScript Object Notation）類型的二進制存

儲版本。通過 JSONB 類型可以對 JSON 格式的文檔數據建立索引，並

可加快對其內部元素的訪問速度。詳細信息請參考 5.6 節，同時可參考

這兩篇博客文章：“Introduce jsonb: A Structured Format for Storing

JSON”以及“JSONB: Wildcard Query”。

GIN 索引改進GIN

索引在設計時已經考慮了要適用於全文搜索、三連詞處

理、hstore 鍵值數據庫以及 jsonb 類型支持等場景。在很多情況下你

甚至可以把它當作 B-樹索引的替代品，一般來說 GIN 索引與 B-樹的查

找效率相當，但佔用空間更少。9.5 版中，GIN 索引的查詢速度被進一

步提升。詳情請參見“GIN as a Substitute for Bitmap Indexes”這篇文章的

介紹。

支持更多 JSON 函數

具體包括

json_build_array、json_build_object、json_object、json_to_record

和 json_to_recordset 等幾個函數。

加速跨表空間的對象搬遷

支持使用以下語法輕鬆地將所有數據庫對象從一個表空間移動到另

一個表空間：ALTER TABLESPACE old_space MOVE ALL TO

new_space;。

支持對返回的結果集中的記錄加上數字編號

現在可以為查詢結果中的記錄添加行號。行號用系統字段

ordinality（該字段是在 ANSI SQL 標準中定義的）表示。當需要將

存儲為數組、hstore 鍵值對或者複合類型的非格式化數據轉換為格式

化記錄時，該功能特別有用。以下是一個使用 hstore 的例子：

SELECT ordinality, key, value

FROM each('breed=>pug,cuteness=>high'::hstore) WITH ordinality;

支持通過執行 SQL 命令來更改系統配置設置利用 ALTER system SET ... 語法，無須修改 postgresql.conf 文件

即可設置全局系統配置。postgresql.conf

文件具體的修改方法請參見

2.1.2

節。這也意味著用戶可以通過編程的方式動態地調整系統配置

項，但請注意：有的配置項修改後需要重啟數據庫才能生效。

觸發器功能增強

9.4 版中支持了對外部表創建觸發器。

數據行轉列能力增強

unnest 函數用於實現數據的行轉列操作，即將一個橫向的數組轉

換為縱向的一個字段的多行記錄。該函數可接受多個數組作為入參，每

個數組轉換後成為單獨的一列，即輸入幾個數組轉換後就有幾列。如果

每個數組的元素個數不一樣，9.4 版之前轉換後的結果是不可預知的，

9.4

版本後這種情況下轉換的結果是可預知的，會以最長的數組為標

準，其他不足此長度的數組元素補 null。

新增 ROWS FROM 語法

該語法可以將多個函數返回的結果集逐行拼接起來，最後作為一個

完整的結果集返回，因此即使這些結果集之間的元素個數不一致也沒關

系，如下例所示：

SELECT *

FROM ROWS FROM (jsonb_each('{"a":"foo1","b":"bar"}'::jsonb),

jsonb_each('{"c":"foo2"}'::jsonb))

x (a1,a1_val,a2_val);

支持動態啟用後臺工作線程

當使用 SQL 或 PostgreSQL 函數都無法實現所需要的功能時，可以使用 C 語言編碼實現動態後臺工作線程來達成目標。9.4 版源碼的

contrib/worker_spi 目錄下實現了一個小型的示例，可供參考。1.7 數據庫驅動程序

任何情況下，你都不可能脫離具體的業務系統而僅僅使用 PostgreSQL

數據庫本身，那顯然是無意義的。為了實現 PostgreSQL 與業務系統之

間的交互，就需要藉助數據庫驅動程序。PostgreSQL 擁有大量免費驅

動，支持各種編程語言和開發工具。此外，很多商業公司也以很低廉的

價格提供了各有特色的驅動。目前比較流行的幾種開源驅動如下。

PHP 驅動：PHP 語言廣泛應用於 Web 開發領域，大多數 PHP 發行

包都自帶了較老的 pgsql 驅動或者是較新的 pdo_pgsql 驅動。一般

來說這兩種驅動默認都會安裝，不過可能需要修改 php.ini 來決定

啟用哪一種。

JDBC 驅動：Java 開發所使用的 JDBC 驅動一直是與最新版

PostgreSQL 同步更新的，可以從 PostgreSQL 官方站點下載。

.NET 驅動：.NET 框架（含微軟的官方版和 Mono 社區的開源版）

可使用 Npgsql 驅動。目前該驅動支持微軟 .NET 框架，包括微軟

Entity Framework 開發框架以及 Mono 開源 .NET 框架。

ODBC 驅動：如果需要從微軟 Access、Excel 或者其他支持 ODBC

的產品連接到 PostgreSQL，可從 PostgreSQL 官網下載 ODBC 驅

動，支持 32 位和 64 位兩個版本。

LibreOffice/OpenOffice 驅動：LibreOffice 3.5 及之後的版本中自帶

了 PostgreSQL 驅動，但 3.5 之前的版本以及 OpenOffice 是不帶

的，可以使用 JDBC 或者 SDBC 驅動。更多細節請參見“OO Base

and PostgreSQL”這篇博文。

Python 驅動：Python 可通過多種驅動訪問 PostgreSQL，目前

psycopg2

是最流行的一種。Python

的

Django

開發框架對

PostgreSQL 也有著良好的支持。如果你需要一個關係 - 對象映射工

具（即通常所說的 ORM 工具），可以考慮使用最廣泛的 SQLAlchemy 工具，著名的外部數據源封裝器開發平臺 Multicorn 內部

就使用了它。

Ruby 驅動：對 Ruby 開發人員來說，請使用 rubygems pg 驅動。

Perl 驅動：Perl 可以使用 DBI 和 DBD::Pg 驅動。也可以使用由

CPAN 網站提供的 DBD::PgPP 驅動。

Node.js 驅動：Node.js 是一個 JavaScript 框架，可用於構建可擴展

的網絡應用。該平臺目前支持兩種 PostgreSQL 驅動：一種是 Node

Postgres，該驅動可以選擇是否綁定本地

libpq

庫，而且基於純

JavaScript（無須編譯）；另一種是 Node-DBI。1.8 如何獲得幫助

在使用 PostgreSQL 的過程中，你遲早會需要尋求幫助，而且這一天往

往會比預期來得早。我們希望你能夠儘早瞭解到求助的途徑。我們最為

推薦的途徑是郵件列表，不管你是 PostgreSQL 的新用戶還是老用戶，

郵件列表都能為你解答技術問題。可以先打開 PostgreSQL 郵件列表頁

面。如果你是新手，那麼訂閱 PGSQL-General 這個郵件列表是最合適

的。如果你認為自己發現了 PostgreSQL 的 bug，那麼打開“PostgreSQL

故障報告”這個頁面，上面會告訴你具體如何操作1.9 PostgreSQL的主要衍生版本

PostgreSQL 使用了 MIT/BSD 風格的許可證，任何人都可以合法地對其

修改並二次傳播，因此對於那些想創建自己數據庫分支的人來說，

PostgreSQL 是絕佳的選擇。在過去的很多年間，有很多團隊創建了自己

的 PostgreSQL 分支版本，並且對社區也做出了相應的回饋，有的把自

己的修改貢獻回了 PostgreSQL 的主幹代碼，有的對社區給予了資金支

持。訪問 https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases 這

個地址，就可以看到 PostgreSQL 數據庫的所有衍生產品。

很多流行的分支版本是商業化的閉源軟件。比如目前數據倉庫領域使用

很廣泛的 Netezza 就是源自 PostgreSQL。亞馬遜公司的 Redshift 數據倉

庫事實上是 PostgreSQL 的一個分支的分支。亞馬遜還有其他兩個與原

生 PostgreSQL 血緣關係較近的產品：Amazon RDS for PostgreSQL 和

Amazon Aurora for PostgreSQL。這兩個產品會與 PostgreSQL 開源版本

的主幹代碼保持同源，並確保與原生 PostgreSQL 提供完全相同的 SQL

語法，同時額外提供了更強的管理功能並在速度方面做了一些優化。

EnterpriseDB 公司推出的 PostgreSQL Advanced Plus 也是以 PostgreSQL

為基礎，另外增加了對於 Oracle 語法和特性的兼容支持，以吸引原

Oracle 用戶。EnterpriseDB 公司向 PostgreSQL 社區提供了資金和開發力

量的支持，對此我們表示感謝。他們的 Postgres Plus Advanced Server 產

品在版本更新節奏上也一直是密切跟進最新的 PostgreSQL 穩定版的。

Postgre-X2、Postgres-XL

和

GreenPlum

是三款還處於發展初期的

PostgreSQL 開源衍生產品，其中 GreenPlum 曾經有一段時間是閉源的。

這三款產品的目標都是處理大規模數據分析和複製工作。

PostgreSQL 之所以衍生版本眾多，部分原因是主幹版本對於一些小眾的需求可能不會及時支持，另外主幹版本的發佈節奏也不能滿足所有人的

要求，那麼自己拉出來一個分支版本提前進行修改和測試就是更好的選

擇。很多這種分支版本中開發出來的新特性最終都匯合到了主幹，比如

2nd Quadrant 公司支持多主和雙向複製特性的 BDR 產品分支中的邏輯

複製功能就被匯合入了主幹，用於強化 PostgreSQL 原生的複製功能。

PostgreSQL-XL 中開發的一些並行化特性將來也可能會合入 PostgreSQL

主幹中。

Citus 是一個支持實時大數據處理和並行查詢功能的 PostgreSQL 分支，

從 PostgreSQL 9.5 開始它被改造成了 PostgreSQL 的一個擴展包，使用

起來更加方便。

Google 最近發佈了它的 Google Cloud SQL for PostgreSQL 產品，目前還

處在 beta 測試階段。

閱讀更多 程序style 的文章

關鍵字: Server P 數據庫