Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
本手冊為PostgreSQL官方手冊翻譯版,由PostgreSQL台灣社群愛好者所提供,描述本版本PostgreSQL的功能與支援情形。
為了更易於閱讀與管理,本手冊以下列數個部份所組成。每一個部份均為不同類型的使用者所撰寫:
PostgreSQL是基於POSTGRES 4.2的物件導向關連式資料庫管理系統,其由美國加州伯克萊大學資訊科學系所研發。POSTGRES所開發的許多重要概念成為許多日後商用資料庫系統重要的一部份。
PostgreSQL由伯克萊大學公開其原始碼所誕生,它支援了大多數的標準SQL語法,並提供許多先進的功能:
complex queries
foreign keys
triggers
updatable views
transactional integrity
multiversion concurrency control
同時,PostgreSQL也支援讓使用者能以自己的方式善用資料庫系統:
data types
functions
operators
aggregate functions
index methods
procedural languages
在使用權利方面,不論任何人以任何目的,使用、修改、散布PostgreSQL,都是被允許的,包含私人使用、商業用途、或學術研究。
本篇談的是如何回報問題到 PostgreSQL 官方組織,而本正體中文手冊並非由官方提供,所以如果你希望指出的問題是本手冊的相關問題,請透過,或所提供的聯絡資訊回報。
如果你在 PostgreSQL 中發現了問題,我們會很希望可以得到通知。你的問題回報可以讓 PostgreSQL 變得更值得信任,因為百密仍有一疏,PostgreSQL 無法保證在任何平台或任何情況下,都一定是完美無缺的。
下面的建議提供你在回報問題時能夠更有效率。你不一定要完全遵照下面的方式,但如果你試著遵循的話,對大家都有幫助。
我們無法保證可以立即修正所有的錯誤。但如果那個問題是明顯的、關鍵的、或是有重大影響的,那就會有人進行瞭解。也可能會回覆你更新你的資料庫版本,如果是因為版本問題的話。我們也可能會判定該錯誤不會被修正,在我們進行重大修改之前;又也許它不容易簡單處理,而且有其他更重要的需求排程已經在進行中。如果你需要立即性的支援,請接洽當地的商業服務。
在報告錯誤之前,請再三閱讀文件,以確認你真的在進行你正在嘗試的事情。 如果從文件中不清楚是否可以做某事,請回報;這是屬於文件的一個錯誤。如果確實證明一個程式與文件所描述地不同,那就是一個錯誤。這可能包括但不限於以下情況:
程式以致命信號(fatal signal)或程式中某個問題造成作業系統錯誤訊息而終止。(反例可能是“磁盤已滿”的訊息,因為您必須自己修復。)
程式對於任何輸入都產生錯誤輸出結果。
程式拒絕接受有效的輸入 (如文件中所定義的)。
程式接受了無效的輸入,卻沒有警告或錯誤消息。但請記住,您對於無效輸入的認知可能來自於我們對傳統做法的延伸或相容性。
PostgreSQL 在支援的平台上,按照指示進行編譯,構建或安裝卻失敗了。
這裡的「程式」是指任何可執行文件,不僅僅是後端執行的程序。
緩慢或資源匱乏不一定是一個錯誤。閱讀文件或在某個郵件列表中提問,可以幫助你調整應用程式。不符合 SQL 標準不代表是錯誤,除非明確聲明相容某個特定的功能。
在繼續之前,請檢查 TODO 列表和常見問題解答,看看您的錯誤是否已知。 如果您無法瞭解 TODO 列表中的資訊,請報告你的問題。 我們至少可以做的是使 TODO 列表更清楚。
關於錯誤報告最重要的是陳述所有事實並且只有事實。不要揣測你的想法是錯的,什麼「似乎」,或程式的哪個部分有故障。如果你不熟悉實作的方法,你可能會猜測錯誤,而無法幫助我們。即使你有知識性的解釋,也應該是對事實的補充而不是替代它們。如果我們要修復這個錯誤,我們還是首先要看到它發生。報告裸露的事實是相對簡單的(你可以從屏幕上複製貼上它們),但是經常重要的細節被忽略,因為有人認為這並不重要,或者認為報告被理解是應當的。
每個錯誤報告中都應包含以下內容:
程式執行步驟的確切順序是重現問題所必需的。這應該是獨立的;如果輸出應該依賴於資料表中的資料,那麼沒有包含前面的 CREATE TABLE 和 INSERT 語句的 SELECT 語句是不夠的。我們沒有時間來對你的資料庫進行逆向工程,如果我們需要建立自己的資料庫的話,我們很可能會錯過這個問題。
SQL相關問題的測試最佳格式是可以透過 psql 執行並重現問題。 (請確認您的 ~/ .psqlrc 啟動設定中沒有任何內容。)建立這個檔案的一個簡單方式是使用 pg_dump 來轉出設定該情境的資料表宣告及資料,然後加入產生問題的查詢語句。我們希望您盡量減少您的問題規模,但這並不是絕對必要的。如果錯誤是可重現的,我們會以任何一種方式找到它。
如果您的應用程式使用某些其他客戶端界面(如PHP),請嘗試突顯那些問題查詢語句。我們應該不會設置一個 Web 伺服器來重現您的問題。無論如何,請記得提供確切的輸入檔案;不要猜測「大文件」或「中型數據庫」等問題的可能性。因為這些訊息不夠精確,沒有參考價值。
你所得到的輸出。請不要說「不能用」或「壞掉了」。如果出現錯誤訊息,請列出來,即使您並不瞭解它。如果程式終止是因為作業系統錯誤,請說明哪個系統錯誤。如果沒有發生任何事情,也如實說明。即使您的測試案例的結果是當機或其他明顯的情況,也不一定會在我們的平台上發生。如果可以的話,最簡單的方法是從終端視窗中複製輸出內容。
注意如果您要報告錯誤訊息,請取得該訊息最詳細的形式。在 psql,事先輸入
\set VERBOSITY verbose
。 如果從伺服器記錄取得訊息,請在執行時將參數 log_error_verbosity 設定為 verbose,以便記錄所有詳細訊息。如果是嚴重錯誤的情況下,客戶端報告的錯誤訊息可能不包含所有可用的信息,還請查看資料庫伺服器的系統記錄輸出。如果你沒有保留伺服器的系統記錄,那麼這是開始這樣做的好時機。
你所期待的輸出情況對於情境說明非常重要。如果你只是寫「這個命令給我這樣的輸出」或「這結果不是我的預期」,我們可以自己運行它,檢視該輸出結果,並認為它看起來正常,正是我們的預期。我們不應該把時間花在解讀你的命令背後確切的語意。特別是不要僅僅說「這不是 SQL 或 Oracle 所做的那樣」。從 SQL 挖掘所謂正確的行為並不是一件有趣的事情,我們更不會知道所有其他關連式資料庫的做法。(如果你的問題是當機,很明顯地你可以省略此項。)
任何命令列選項和其他啟動選項,包括您從預設值修改的任何相關的環境變數或設定檔案。再次提醒,請提供確切的訊息。如果您正在使用預先封裝好的套件,在開機時啟動資料庫伺服器,您應該嘗試瞭解它如何進行。
所有你所做的與安裝說明不同之處。
PostgreSQL 的版本。你可以執行SELECT version();
來找到你正在連線的資料庫系統版本。大多數的程式工具也會支援--version
選項;至少postgres --version
和psql --version
都可以使用。如果功能或選項不存在,那麼您的版本已經太舊而無法進行升級。如果您運行預先編譯的套件(如 RPM),請說明,包括該套件可能具有的子版本。如果您正在使用 Git 某個快照,請說明快照版本,包括提交碼(commit hash)。
如果您的版本比10還舊,我們幾乎肯定會告訴您進行升級。每個新版本都有很多錯誤修復和改進,所以很可能在PostgreSQL的舊版本中遇到的錯誤已經被修復了。我們只能對使用較早版本的PostgreSQL伺服器提供有限的支援;如果你的需求多於我們所能提供的,請考慮取得商業支援合約。
執行平台資訊。這包括作業系統核心名稱和版本,C語言函式庫,中央處理器、記憶體資訊等等。在大多數情況下,報告系統供應商和版本是足夠的,但不要假設每個人都知道「Debian」究竟是什麼,或是每個人都運行在 i386 上。如果您有安裝問題,則還需要你的機器上有關系統工具組的訊息(編譯器、make 工具等等)。
不要花所有的時間來指出輸入中的哪些變化會使問題消失。這可能對解決問題沒有幫助。如果事實證明該錯誤不能立即解決,您仍然有時間找到並分享您的解決方案。此外,再一次,不要浪費你的時間猜測為什麼這個問題會存在。我們會很快找到。
在撰寫錯誤報告時,請避免混淆術語。這個軟體整體來說被稱為「PostgreSQL」,有時候會簡稱為「Postgres」。如果你特別在談論後端的程序,請明確指出,而不要只是說「PostgreSQL 當掉了」。其中一個後端程序的當掉與主要的「postgres」程序當掉有很大的不同;當你的意思是某個後端程序終止時,請不要說「伺服器當掉了」,反之亦然。此外,例如交互式前端的「psql」用戶端程序與後端完全分離的。請嘗試具體說明問題是在用戶端還是伺服器端。
注意
歡迎來到 PostgreSQL 的新手教學。在這個部份裡的內容,主要提供有關於 PostgreSQL 各項功能的簡介、關連式資料庫概念、以及 SQL 語法的入門說明。我們只假設您俱備一些電腦系統基本操作,並不需要很專業的 Unix 或程式設計經驗。這裡主要提供一些實用的經驗,還有 PostgreSQL 系統中重要部份的介紹。在這個部份並不會進行所有議題的詳細說明。
在你閱讀完新手教學之後,也許可以繼續閱讀:更多有關於 SQL 語法的標準知識;或者到:瞭解如何開發 PostgreSQL 的應用程式;而如果你需要建置及管理你的資料庫伺服器的話,請參閱的內容。
不要擔心你的錯誤報告會因此而變得冗長。這是一個事實過程的呈現。第一次報告所有事情,對我們比較好的做法是,儘量把事實從你身上擠出來。 另一方面,如果你輸入的檔案很大,持平來說,首先要問是否有人有興趣去研究它。這裡有一篇,概述了有關報告錯誤的更多建議。
一般來說,將錯誤報告發送到錯誤報告的郵件列表:<
>
。你需要為你的電子郵件使用描述性主題,可能是錯誤消息的一部分。
另一種方法是填寫上提供的錯誤報告網頁式表單。用這個方式的話,它也會把內容轉寄到<
>
郵件列表之中。
如果您的錯誤報告隱含有安全疑慮,並且您希望它不會在公共討論區中立即顯示,請不要將其發送到pgsql-bugs。安全問題可以非公開地回報至<
>
。
不要向任何用戶的郵件列表發送錯誤報告,像是<
>
或<
>
。這些郵件列表用於回答用戶的問題,用戶通常不希望收到錯誤報告。 更重要的是,他們不太可能修復它們。
另外,請不要向開發者的郵件列表發送報告<
>
。這個列表用於討論 PostgreSQL 的開發,如果我們可以將問題報告分開來,那將是很棒的。 不過,我們可能會選擇討論你的錯誤報告pgsql-hackers
,如果那個問題需要更多討論的話。
如果你的問題是使用手冊,回報問題的最佳位置是使用手冊的郵件列表<
>
。請具體說明文件的哪一部分讓你不滿意。
如果您的錯誤是非支持平台上的可移植性問題,請寄送郵件到<
>
,讓我們(和你)可以將 PostgreSQL移植到你的平台上。
不幸由於垃圾郵件數量,所有上述電子郵件地址都是封閉的郵件列表。也就是說,您需要訂閱列表才能發布。(然而,您不需要訂閱使用錯誤報告Web表單。)如果你想發送郵件但不想接收郵件列表,您可以訂閱並設置您的訂閱選項為「nomail」。想得到更多訊息的話,請寄一封郵件到 <
>,內文請輸入「help」一個單字,就會自動回覆你進一步的訊息。
版本:11
1.1. 安裝:從無到有,安裝一個 PostgreSQL 資料庫系統。
1.2. 基礎架構:認識 PostgreSQL 的資料庫架構。
1.3. 建立一個資料庫:建立第一個 PostgreSQL 資料庫。
1.4. 存取一個資料庫:開始存取你的 PostgreSQL 資料庫。
以下所提到慣例,用於指令的語法描述上(均為半型字元): 中括號( [ 和 ] )指可選擇是否輸入的選項。(在Tcl指令的語法中,習慣使用問號?表達這樣的可選擇性) 大括號( { 和 } )及垂直線( | )指的是必須要輸入的部份。 連續句點(...)指的是該段落可以允許不斷重覆。
為了使說明更簡潔,SQL指令使用提示字元"=>",作業系統命令列指令則使用"$"。雖然一般而言,提示字元可能不會顯示。
Administrator一般的定義是負責安裝及運行資料庫系統的人;User指的是任何正在使用資料庫的人,或者正要使用任何PostgreSQL相關系統的人。這些定義不應該被解釋得太過嚴格,在本文件中,對於系統管理的工作,並沒有固定的假設。
版本:11
在開始使用之前,你需要瞭解基本的PostgreSQL系統架構。認識PostgreSQL如何回應操作,有助於讓你更清楚瞭解以下的說明。
以資料庫的述語來說,PostgreSQL採用了主從式架構(client/server)。PostgreSQL會在進行下列操作時保持連線:
伺服器的執行緒,負責管理資料庫的檔案、受理用戶端的連線要求、執行相對應的資料庫動作。這樣的資料庫伺服端程式稱之為「postgres」。
用戶端的程式用來發起資料庫操作的行為,其設計的形態很廣泛:可能是文字介面的工具、圖型介面的程式、將資料庫內容顯示成網頁的網際網路伺服器、甚或是專用的資料庫管理工具。有一些用戶端程式是由PostgreSQL官方所提供,大部份由第三方的其他使用者所開發。
如同一般的主從式架構,用戶端與伺服端可以是兩台不同的主機,而他們透過TCP/IP的網路協定溝通。你應該將這個觀念謹記在心,因為某些在用戶端可以被存取的檔案,在伺服端可能就無法存取(或使用不同的檔案名稱)。
PostgreSQL伺服器可以管理來自多個用戶端的同步連線。為了達到這樣的功能,它會自我複製(fork)成新的執行緒,一對一地處理每一個連線。這個部份進一步來說,用戶端和新的伺服器執行緒之間的溝通,並不需要原始的postgres執行緒介入。也就是說,主要的資料庫服務執行緒會持續等待其他用戶端的連線,協助安排好其與伺服端執行緒的配對之後便完全交接,再回到等待的狀態。(當然,使用者完全不會察覺這些行為,在此說明僅僅是為了整體性的概念描繪)
版本:11
本章適合初學資料庫的朋友閱讀,以簡單的語法範例,實際操作以瞭解資料庫的運作方式。事實上,更複雜的資料庫行為,也不脫這個基本的操作模式。
PostgreSQL目前為眾所皆知的物件導向的關連式資料庫管理系統,其由美國加州伯克萊大學所研發的POSTGRES衍生而成。經過超過二十年以上的演進,PostgreSQL現在是世界上最先進的開源資料庫系統。
POSTGRES專案是由Michael Stonebraker教授領導的團隊進行研發,其受到Defense Advanced Research Projects Agency (DARPA),the Army Research Office (ARO),the National Science Foundation (NSF),及ESL, Inc的贊助。POSTGRES專案始於1986年,最原始的設計,"The design of POSTGRES",作為開端,其最初的資料結構模型則揭露於"The POSTGRES data model"。規則系統設計發表於"The design of the POSTGRES rules system",而當時的關連式資料儲存的架構則刊載於"The design of the POSTGRES storage system"。
POSTGRES接下進行了幾次重大的變革。第一代的"demoware"在1987年真的實作成為可用的系統,並在1988年的ACM-SIGMOD研討會中進行展示,並在1989年6月,釋出了第1版可供外部使用者使用的資料庫系統。為了回應當時使用者對於第一代規則系統的批評,其規則系統重新進行設計,並在隔年1990年的6月份,隨即推出第2版系統,搭載新的規則系統設計。第3版系統則於1991年發表,新增支援多重儲存管理機制,改善查詢處理器,並又改寫了規則系統。如此直到Postgres 95誕生之前,主要都專注於移植性及可信賴度的發展。
POSTGRES接下來開始被運用在許多不同的研究和產品上,財務資料分析系統、噴氣引擎效能監控系統、小行星追蹤資料庫、醫療資訊系統、以及數個地理資訊系統。POSTGRES也被好幾所大學用於其教學工具。最後,由Illustra Information Technologies(後來併入,而Informix目前為所擁有)技術移轉,並將其商業化。於1992年末,POSTGRES成為主要的資料管理系統。
在1993年間,用戶數量呈現倍數成長,伴隨而來的是大量的程式碼維護與服務支援,占去絕大部份原來應該進行研究的時間。為了減少維運的負擔,伯克萊的POSTGRES專案正式終止於4.2版。
1994年,Andrew Yu和Jolly Chen在POSTGRES增加了SQL語法的直譯器,並且以新的Postgres 95為名,在網路上開放讓全世界的人使用。他們成為伯克萊POSTGRES原始碼最初的繼承者。
Postgres 95的程式碼是完全以ANSI C開發,並且輕量化了25%。許多內部的改良增進了效率及可維護性。當時Wisconsin Benchmark進行測試,Postgres 95在1.0.x時的效能比原始的POSTGRES 4.2快了約30%至50%。除了一些錯誤修正之外,還有下面這些主要的改良:
原有的PostQUEL以SQL(實作於伺服器端)所取代。(連接介面在PostQUEL之後便採libpq函式庫) 子查詢一直到PostgreSQL出現之前都還未支援,但在Postgres 95便已能使用自訂的SQL函數,聚合函數Aggregate function則被重新實作。GROUP BY查詢語句也在此時被加入。
新的工具psql可進行互動式的SQL操作,其採用的是GNU Readline的技術。psql開始大量取代老舊的管理工具。
新的前端函式庫,libpgtcl,支援Tcl-based用戶端程式。還有一個簡易的命令列介面工具pgtclsh,使用新的Tcl命令和Postgres 95伺服器進行操作。
重新改寫了large-object處理的交換介面,僅使inversion作為儲存大型物件的唯一機制。(inversion檔案系統就此移除)
Instance-level的規則系統被淘汰了,但其規則仍用於重構規則所使用。
製作了一個簡短的說明,介紹標準的SQL功能,並隨Postgres 95原始碼發佈。
使用GNU make(取代BSD make)編譯程式碼,Postgres 95也支援使用未修正的GCC編譯器(修正高精度資料對齊問題)。
1996年,"Postgres 95"這個名稱很明顯不再適合。我們選擇了新的名稱,PostgreSQL,其呈現出與原始POSTGRES之間的源由,也彰顯了結合SQL力量的意義。同時,我們設定其版本由6.0開始,重回伯克萊POSTGRES專案的版號序列。
許多人持續使用"Postgres"(現在已經很少使用全大寫字母表現)來代表PostgreSQL,是因為傳統,也可能是因為比較好發音。這樣的用法也廣為用於暱稱或別名。
Postgres 95的發展主要在於瞭解及定義伺服器程式既有的問題,而PostgreSQL則更重視系統的能力與爭議性的功能上,不過所有的工作是全面性的。
更多有關於PostgreSQL的發展,請參閱附錄E。
除了本文件之外,PostgreSQL還有其他的參考資訊:
PostgreSQL的記錄了,,以及其他更多不同主題的資訊。
PostgreSQL wiki 也有的頁面喔。
PostgreSQL的,有最新軟體的釋出訊息,讓你能夠和PostgreSQL相處得更棒!
郵件列表的功能,是一個為您解答疑問的好地方,你也可以分享使用經驗給其他同好,或直接和開發者溝通。 詳情請參閱PostgreSQL的官方網站。
PostgreSQL是一個開源的專案,也就是說,它仰賴社群的每一個人給予支持。當你開始使用PostgreSQL,你會需要其他人的幫助,可能是透過文件或是郵件列表的功能。請考慮也可以回饋您的知識。在閱讀郵件列表和回答疑問的同時,如果你學到了未被文件記載的知識時,請寫下來,並且供獻出來。如果你撰寫了一些程式碼增加了特別的功能,也希望能夠回饋到社群之中。
版本:11
你需要先進行安裝,才能開始使用PostgreSQL。當然,PostgreSQL也可能已經被安裝在你的系統之中,因為你的作業系統預設套件包含了PostgreSQL,或其他系統管理者已先行安裝。如果是這樣的話,那麼你應該先瞭解作業系統的資訊,或向你的系統管理員取能存取的資訊。
如果你並不確定PostgreSQL是否已經可以使用,或者你也可以自行安裝試試。這樣做並不是很困難,而且是很好的操作練習。PostgreSQL可以以一般使用者進行安裝,它並不需要系統管理者(root)的權限才能安裝。
如果你打算自行安裝PostgreSQL,你可以參考第16章的指令進行,完成之後再回到這裡,以瞭解接下來關於設定環境變數的內容。
如果你的系統管理者並非以預設的方式安裝,你可能還有一些額外的工作要做。例如,如果資料庫主機其實是遠端的伺服器,你會需要設定PGHOST的環境變數,將其指向資料庫主機的網路名稱。而PGPORT變數也是必須要設定的。最基本的情境是,如果你嘗試啓動一個應用程式,而它回報它無法取得資料庫連線時,你就必須洽詢你的系統管理者。而如果系統管理者就是你自己,那麼你應該依文件再確認你的環境設定是正確的。如果你仍然並不清楚前面所描述的事項,請詳細閱讀的內容。
版本:11
一旦你已經建立一個資料庫,你就可以開始以下列方式進行存取:
執行 PostgreSQL 互動式的終端程式,稱作 psql,它可以讓你輸入、編輯、執行 SQL 指令。
使用既有的圖型化介面工具,例如 pgAdmin 或是支援 ODBC 或 JDBC 的辦公室軟體,以建立並輸入資料到資料庫裡。不過這部份並未包含在這份手冊之中。
自行撰寫一個程式,可以使用許多種程式語言來完成。這個部份將會在第 IV 章中進行介紹。
在這份指南中,你可能會先使用 psql 來進行一些嘗試。你可以藉由下列指令開始操作 mydb 這個資料庫:
如果你並未指明資料庫名稱,那麼它預設會以你的使用者名稱作為資料庫名稱。在先前的章節使用 createdb 時,你已經知道這個隱含的規則了。
在 psql 中,你會以下列訊息開始:
最後一行也可能是:
這表示你是資料庫的超級使用者(superuser),如果你是自行安裝 PostgreSQL 的話,大概就會是這個情況。 作為一個超級使用者,表示你不會受限於任何存取控制。不過在這份指南中,這並不是重要的事。
如果你在啓動 psql 時遭遇了一些問題,那麼請回到前一節。createdb 和 psql 的行為很類似,如果前者正常,後者也應該如期運行。
最後一行會輸出的是 psql 的提示字串,它表示 psql 正在等待你輸入 SQL 查詢語句。試試下面的指令吧:
psql 程式中也內建了一些非 SQL 的命令。他們會以倒斜線( )起頭。舉例來說,你可以輸入下列指令以取得一些有關 PostgreSQL 所支援的 SQL 語法資訊:
要離開 psql 的話,請輸入:
如此的話,psql 將會結束,並回到你的命令列介面之中。(想瞭解更多內建指令,在 psql 提示字串後輸入 \? 。)完整的 psql 說明,都記載在 之中。在這份指南中,我們並未使用這些功能,但你可以在需要的時候使用他們。
版本:11
PostgreSQL 是一個關連式資料庫管理系統(RDBMS)。這表示它是一個管理關連性質資料的系統。關連性,基本上在數學裡是以資料表(table)的形式來表現的。今天,以資料表為形式儲存資料是很常見的事,它是很自然的表現,但也有很多其他組識資料庫的方式。在 Unix-like 的作業系統中,檔案和目錄是一個階層式資料庫的案例。更先進的發展是採用物件導向式的資料庫。
每一個資料表是很多資料列(row)的集合。而每一個資料列則以許多相同集合的欄位(column)所組成。每一個欄位都被指定了特定的資料型別。每一個資料列中欄位的次序是固定的。很重要且必須記得的是,SQL 並不保證資料列在資料表中的次序(雖然他們可以在顯示的時候被明確表現)。
一個資料庫中集合了許多資料表,而很多的資料庫則被一個 PostgreSQL 服務所管理,形成一個資料庫叢集。
版本:11
到目前為止,我們的一個查詢都只涉及到一個資料表。其實可以在同一個查詢中,同時查詢多個資料表,或者在同一個資料表之中同時處理多個資料列的資料。在一個查詢之中,涉及到同一個或多個不同的資料表中的資料,稱作為交叉查詢(join)。舉個例子來說,你希望同時列出天氣和城市位置的資料。要完成這項工作,我們需要關連資料表 weather 中的 city 欄位與表格 cities 中的 name 欄位,然後回傳符合條件的資料。
這只是一個概念式的模形,交叉查詢(join)會以更有效率的方式運行,並非真正需要比較每一種組合是否符合條件,不過這些過程對於使用者而言並不會產生操作或結果上的差異。
下列查詢會產生交叉查詢的結果:
在這個結果中可以觀察到兩件事情:
不會有關於 Hayward 的結果出現。這是因為在資料表 cities 中未有 Hayward 的資料,所以交叉查詢會忽略資料表 weather 中未能關連的資料。關於這點,我們很快就會有解決辦法。
有兩個欄位顯示了城市的名稱。這樣是正確的,因為來自於資料表 weather 和 cities 的欄位被串連起來了。實務上,這樣的結果並不令人滿意,所以也許你可以明確地指出輸出的欄位,取代「 * 」的使用:
練習:試試看,當 WHERE 表示式被省略的話,查詢語句的意義會怎麼樣?
因為所有的欄位都使用不同的名稱,所以解譯器會自動發現他們所屬的資料表為何。如果在兩個資料表之中,存在有相同名稱的欄位時,你最好明確指出確定的欄位,如下所示:
多數開發者認為,在交叉查詢中,明確指出確定的欄位名稱,是良好的撰寫習慣。這樣查詢就不會因為有相同的欄位名稱而產生錯誤。而相同名稱的欄位可能是開發後續才加入的,未指明的話,就可能造成意外的結果。
交叉查詢也可以寫成如下的另一種形式:
這種語法並不如上述的常見,但我們會在這裡說明,以幫助你在後續章節的學習。
現在我們要回到前面的問題,把 Hayward 的資料放在輸出的結果之中。我們要在查詢中做的是,掃描資料表 weather,找到有所關連的每一列資料;沒有關連到的資料列,我們要填上「空值」(null)在資料表 cities 相對的欄位之中。這樣的查詢我們稱作「外部交叉查詢」(outer join)。(先前的交叉查詢為「內部交叉查詢」(inner join))。這樣的查詢指令如下所示:
這種查詢稱作為「左側外部查詢」(left outer join),因為這個交叉查詢,放在左側的資料表中的資料列,一定會在結果中至少出現一次,而右側的資料表中,則只有輸出有關連到左側資料表的資料列。當左側資料表的資料列,並沒有在右側資料表中被關連到時,屬於右側資料表的欄位就會被填上空值輸出。
練習:也有「右側外部交叉查詢」(right outer join)和「完全外部交叉查詢」(full outer join),試著找出他們都做了些什麼。
我們也可以對同一個資料表做交叉查詢,稱作為「自我交叉查詢」(self join)。接下來的範例,假設我們希望找到所有氣溫範圍的天氣資料。所以我們需要讓 temp_lo 及 temp_hi 兩個欄位,和其他的 temp_lo 及 temp_high 相比較。我們可以用下列的查詢來符合需求:
這裡我們重新命名了資料表 weather 為 W1 及 W2,以在交叉查詢中區分左側及右側。你也可以在其他查詢中使用這個技巧,以節省輸入的複雜度,例如:
你將會在後續內容中,不斷練習到這樣的使用方式。
版本:11
在這一章之中,提供了一個如何使用 SQL 進行簡易操作的大致概念。這裡主要讓你有基本的認識,但無法提供 SQL 完整且巨細靡遺的說明。許多書籍詳細介紹了 SQL,例如「Understanding the New SQL. A complete quide.」及「A Guide to the SQL Standard. A user's guid to the standard database language SQL.」。你應該瞭解的是,一些 PostgreSQL 語法來自於標準 SQL 的延伸。
在下面的例子當中,我們假設你已經建立了一個資料庫 mydb,如同前面章節所述,你也能夠使用 psql 了。
這些例子也放在 PostgreSQL 的原始碼之中,你可以在目錄 src/tutorial/ 下找到他們。(PostgreSQL的可執行套件可能未包含這些檔案)想要使用這些檔案的話,首先請切換到該目錄之下,然後執行 make:
這將會建立編譯 C 語言的程序,包含了使用者自訶的函式及型別。接下來,進行下列動作,以開始這個導覽:
\i 指令會去指定的檔案讀取內容,並且執行。而在 psql 的 -s 選項則可以使用單步模式執行,也就是在每一個與伺服器互動的指令之後暫停。這個指令被使用在本節的檔案 basics.sql 之中。
版本:11
你可以創建一個新的資料表,為它取一個名字,並且宣告所有的欄位名稱與其資料型別:
你可以把上述內容在 psql 中輸入,包含換行字元不會影響判讀。psql 是以分號作為指令結束的判定。
空白(包含「空白」、「定位符號」和「換行符號」)都可以自由使用在 SQL 指令當中。這表示你可以將指令以不同的形式排版,甚至全部寫都在一行也沒問題。使用破折號,連續2個("--"),表示緊接的內容只是註解,直到該行結束為止。PostgreSQL 是不分大小寫字母的,包括各類關鍵字和描述語,除非是使用雙引號括起來的文字。(更精確地說,沒有被雙引號括起來的識別字,都會轉為小寫字母進行識別)
varchar(80) 表示指定一個資料型別,它可以儲放任意 80 個字元以內的字串。int 是一般認知的整數型別。real 表示資料是單精確度的浮點數。date 顧名思義,就是日期時間型別。(本例中欄位名稱和型別都使用 date,這可能是方便,也可能是困擾,端看你如何使用。)
PostgreSQL 支援標準的資料型別 int, smallint, real, double precision, char(N), varchar(N), date, time, timestamp, interval,也支援了複合型的地理資料型別。PostgreSQL 可以自訂組合任意數量的資料型別。語法上,資料型別名稱並不是保留關鍵字的範圍,除非特定的標準 SQL 支援需求之外。
第二個例子用來儲存城市及其所在的地理位置:
point 型別是一個 PostgreSQL專屬資料型別的範例。
最後,應該被點出來的是,如果你不再需要一個表格,或者想要重新以別的方式創建它,那麼你可以以下列的指令來移除它:
版本:11
INSERT 指令被用來將資料以資料列(row)的形式,新增至資料表(table)之中:
注意,所有的資料型別都有明確的輸入格式。只要不是簡單的數值內容,都必須要以單引號(')括住,如同在本例中的形式。日期時間型別(date type)的資料內容就比較有彈性,但在這個導覽之中,我們仍然使用較固定的格式來表現。
地理資訊型別(point type)需要有座標組作為輸入,如下所示:
到目前為止,語法的使用需要你依照欄位宣告的次序擺放,而另一種語法可以允許你明確地指定資料相對應的欄位:
你可以將欄位以不同的次序擺放,甚或略去某些欄位,例如,precipitation 欄位(prcp)內容未知:
許多開發者會認為,在撰寫習慣上,明確指定欄位是比較好的方式。
請執行下列的指令,你將會擁有後續章節所需要的範例資料。
你可能需要使用 COPY 這個指令從文字檔案來載入大量的資料。這個指令會比 INSERT 要快上許多,因為 COPY 指令的設計就是為了大量資料輸入而產生的。它少了一些彈性,但提供了效率上的最佳表現。使用範例如下所示:
資料來源的檔案必須存在於後端的伺服器之中,並且可被 PostgreSQL 使用者(postgres)所存取,注意不是用戶端的主機,因為後端伺服器的服務需要直接讀取該檔案。你可以取得更多詳細說明,在 COPY 指令的說明頁面。
版本:11
要從資料表(table)中取出資料,稱作資料表的查詢。要進行這個行為,你需要 SQL 中的 SELECT 指令。這個指令由幾個部份所組成,回傳列表(select list,想要回傳的欄位)、資料表列表(資料來源的資料表)、選擇性的條件定義(指定一些限制條件)。舉個例子來說,要取得資料表 weather 中所有的資料的話,請輸入:
這裡的星號 * 表示「所有欄位」。下列的指令會回傳相同的結果。
其輸出結果將會如下所示:
你可以在回傳列表中撰寫一些運算表示式,而不只是簡單的欄位引用。舉例來說,你可以輸入:
這應該會產生這樣的結果:
注意,「AS」被用來重新命名輸出的欄位。(選用)
查詢語句可以加上「WHERE」來設定限制條件,以指定哪些列才需要被回傳。WHERE 的內容是一個布林(truth value)表示式,而只有在其運算值為真(true)時,該列才會被回傳。一般的布林運算子(AND, OR, NOT)都是被允許出現在表示式中的。舉例來說,下列的指令將會回傳 San Francisco 在雨天的天氣數值:
結果:
你可以將結果進行排序:
在這個例子之中,其次序並沒有完全地被指定,所以你可能會得到 San Francisco 的列以另一種次序呈現。而你如果以下列指令查詢的話,那你就會得到如上但固定的結果:
你可以在查詢時去除重覆的列:
再一次,其結果的次序可能每次都不同,你可以同時使用 DISTINCT 及 ORDER BY 來確保能得到一致性的查詢結果:
版本:11
第一個測試確認你是否能夠存取一個資料庫服務,就是嘗試去建立一個資料庫。一個執行中的 PostgreSQL 服務可以管理許多個資料庫。一般來說,每一個專案或使用者會分開使用不同的資料庫。
你的系統管理員也可能已經為你建立了一個資料庫,如果是這樣的話,那你可以略過本節說明,直接進入到下一節的內容。
要建立一個新的資料庫,在本例中取名叫「mydb」,你可以使用以下的命令:
如果在這個步驟沒有產生任何回應,那就是成功了。你可以跳過本節剩餘的部份。
但你如果看到如下的訊息:
這個訊息代表 PostgreSQL 並沒有被正確的安裝。不是它沒有被安裝好,那就是你的命令路徑設定並未包含這個指令。 嘗試使用下列這個包含絕對路徑的指令看看:
命令路徑在你的系統可能會有些不同。洽詢你的系統管理員,或著檢查安裝步驟以修正這個情況。
另一種回應可能是如此:
這代表了資料庫服務尚未啓動,或者它並不存在於createdb預設連線的位置。同樣地,檢查安裝的步驟或洽詢系統管理者。
而另一種回應也可能是:
這裡指出你用來連線的使用者名稱。這種情況可能會發生在你的資料庫管理員並未建立屬於你的資料庫。(PostgreSQL 的使用者帳戶是獨立於作業系統的使用者帳戶的)如果你是資料庫管理員,請參閱第 21 章,進行建立資料庫帳戶。你必須是 PostgreSQL 初始安裝的管理者(通常是 postgres),以建立第一個一般資料庫使用者的帳戶。這個情況也可能發生在,你被發配的 PostgreSQL 使用者名稱有別於你的作業系統使用者名稱,如果是這樣的話,那你需要在指令上使用 -U 選項,或者設定 PGUSER 環境變數,以指定你的 PostgreSQL 使用者名稱。
如果你有一個資料庫帳戶,但你並沒有建立資料庫的權限,你將會看到下列訊息:
並非每一個使用者都被授權可以建立一個新的資料庫。如果 PostgreSQL 拒絕你建立資料庫,那麼系統管理者就需要賦予你建立資料庫的權限。洽詢你的系統管理者,如果是這種情況的話。如果你是自行安裝 PostgreSQL,那麼你應該以你啓動資料庫服務的使用者登入作業系統,再嘗試這個操作。
你也可以建立資料庫,但使用其他的名稱。PostgreSQL 允許在資料庫系統中建立無限制數量的資料庫。資料庫名稱必須是以英文字母為開頭,總長度限制為 63 位元組。一個簡便的方式是,建立一個與你使用者名稱同名的資料庫。許多工具會預設假定資料庫名稱和你同名,所以這可以省略一些文字的輸入。要建立這樣的資料庫,只要簡單地輸入:
如果你不再使用你的資料庫,你可以移除它。舉例來說,你是 mydb 這個資料庫的擁有者(建立者),你可以使用下列指令來消毁它:
(對這個指令來說,資料庫名稱並不會預設使用你的使用者同名資料庫。你必須明確地指定名稱)這個動作會完全地移除所有和這個資料庫相關的檔案,並且沒有回復的可能,所以要進行這個動作的話,請一定要考慮清楚。
讓我們回到 2.6 節的查詢範例。假設關連天氣資訊和城市位置的結果,是你的應用中特別常用的,但你並不想要每次都要輸入一長串的查詢語句。那麼,你可以為這個查詢語句建立一個「檢視表(View)」,你可以取一個名字,當你需要使用的時候,你可以把它當作一個資料表來使用:
妥善地使用檢視表,對於良好的 SQL 資料庫設計而言,是很關鍵的部份。檢視表允許你可封裝你的資料表結構與細節,當你的應用系統在逐步發展成熟的過程中,扮演一致性的資料介面。
檢視表可以用在大多數資料表可以使用的地方。而用檢視表來封裝其他檢視表的情況,也不少見。
版本:11
如同其他的關連式資料庫產品,PostgreSQL 也支援彙總查詢的功能。彙總查詢指的是能夠把多個資料列的資料經過計算,產生單一結果的功能。舉例來說, count、sum、avg(平均值)、max(最大值)、min(最小值)都是彙總查詢的函式。
這裡的例子,我們可以得到所有低溫中的最大值:
如果我們想要知道,這個數值是發生在哪一個城市?也許可以試試:
不過,這行不通,因為 max 不能使用在 WHERE 條件式當中。(會有這樣的限制,是因為 WHERE 條件式目的是要判斷有哪些資料列的資料應該被彙總計算,所以很明顯地,這件事必須要在彙整計算前發生,這就產生了矛盾。)所以,像本例的查詢一般會使用子查詢(subquery)來取得適當的結果:
這樣就對了,因為子查詢是一個獨立的查詢,它可以獨立進行彙總查詢,有別於括號以外的查詢語句。
彙總查詢和 GROUP BY 一起使用會很方便的。舉例來說,我們可以得到每個城市所觀測到的最高氣溫:
這個查詢對每個城市都輸出一列的結果。每一個彙總的結果,將整個資料表,以關連到的城市進行計算。 而我們可以進一步過濾資料內容,使用 HAVING:
如果限制所有 temp_lo 的數值必須要小於 40 (WHERE temp_lo < 40)的話,也可能得到相同的結果。 最後,如果我們只關心以"S"開頭的城市的話,可以這樣做:
這裡很重要的是,瞭解 SQL 中 WHERE 和 HAVING 之間的行為。其根本上的差異是:WHERE 會在合併和彙總計算之前進行選擇資料的動作(也就是它控制著,哪些資料需要被彙總計算);而 HAVING 是在合併及彙整計算之後,才進行過濾資料的動作。所以,在 WHERE 條件式當中,絕不可以使用彙整運算式;另一方面,HAVING 條件式總是使用彙整運算式。(嚴格來說,你也可以不在 HAVING 條件式中使用彙整運算式,但很少人這樣使用,通常就會改寫到 WHERE 條式件當中,那會更有效率。)
在先前的例子當中,我們可以把城市名稱的限制放在 WHERE 條件式之中,因為它不需要彙總。這將會比放在 HAVING 條件式中更有效率,因為這樣可以避免合併及彙整運算整個表格,不用浪費時間在本來就會被過濾掉的資料上。
在前面的章節,我們介紹了如何使用 SQL 來存取 PostgreSQL 的基本方式。接下來,我們將會討論更多先進的功能,SQL 的管理功能以及防止資料遺失或損毁。最後,我們也會介紹一些 PostgreSQL 的延伸功能。
這個章節偶爾會引用的範例,試著去改寫或是優化他們,所以閱讀過上一章也是很有用的。在這一章中有一些範例是來自於 tutorial 目錄中的 advanced.sql,這個檔案有一些範例資料可以載入,但載入方式在此就不再贅述。(請參閱 的內容)
版本:11
要把某些資料列從資料表中移除,就使用 DELETE 這個指令。假設你對於 Hayward 這個城市的天氣不再感興趣了,那麼你可以執行下列指令,來刪除資料表中的這些資料:
所有關於 Hayward 的資料都被刪除了。
這個指令有一個應該要特別注意的情況:
沒有任何限制的條件,DELETE 將會刪去所有該資料表中的資料,使成為空的資料表。資料庫系統並不會在這個動作執行前和你確認!
回想一下在中的表格 weather 及 cities,思考下列問題: 你想要保證沒有另一個人可以新增在 cities 中沒有的城市資料到 weather 中。這就是所謂資料關連性的管理。在簡單的資料庫系統當中,可能會這樣實作:先檢查 cities 中是否已有對應的資料,然後再決定資料表 weather 中新增或拒絕新的天氣資料。這個辦法還有很多問題,而且很不方便,所以 PostgreSQL 可以幫助你解決這個需求。
新的資料表宣告如下所示:
現在嘗試新增一筆不合理的資料:
外部索引鍵或簡稱外部鍵(foreign key)的行為可以讓你的應用程式變得容易調整。我們在這個導覽中不會在深入這個簡單的例子了,但你可以在取得進一步的資訊。正確地使用外部索引鍵,可以改善資料庫應用程式的品質,所以強烈建議一定要好好學習它。
LIKE 運算子進行特徵比對運算,這將會在 中進一步說明。
PostgreSQL 還有許多這份導覽中未能介紹到的功能,這裡主要是針對新鮮的 SQL 使用者所準備的內容。 這些功能將會在後續的章節進行更詳細的討論。
如果你覺得你需要更多介紹的資訊,可以到 PostgreSQL 的官方網站取得更多訊息。
在這個部份介紹如何在 PostgreSQL 中使用 SQL 語言。首先,我們從一般性的 SQL 語法開始說明,然後解釋如何建立結構來保存資料,如何充實資料庫,以及如何查詢資料的方法。中段的部份列出 SQL 指令中的資料型別與函數。最後剩餘的部份,將會針對一些調教資料庫的重要議題進行說明。
這個部份的內容設計讓初學者可以循序漸進地完整瞭解該主題,而不需要反覆前後查閱。各章的內容設計上都是獨立的,所以進階的使用者可以分別閱讀他們需要的部份。在這個部份的內容,針對於主題式的單元描述。需要瞭解詳情的讀者,請參閱第 6 部份中,個別指令的說明頁面。
在這個部份裡的讀者,應該要知道如何連線到一個 PostgreSQL 資料庫,並且執行 SQL 指令。如果不熟悉這些操作的讀者,建議先閱讀第 1 部份的內容。SQL 指令一般是使用終端工具 psql,但其他具有類似功能的程式也可以使用。
版本:11
你可以使用 UPDATE 指令以列為單位來更新資料。假設你發現氣溫的數值測量在 11 月 28 日之後都多了 2 度。你可以以下列語法來修正這些資料:
查看一下這些更新後的資料:
這章中說明 SQL 的使用語法。從這裡建立後續章節所需的理解基礎,然後進一步瞭解 SQL 如何使用去定義及修改資料。
我們也建議已經熟悉 SQL 語法的使用者,仔細地閱讀本章,因為這裡包含了一些有別於其他 SQL 資料庫或專屬於 PostgreSQL 的規則和觀念。
繼承是一個物件導向資料庫的概念,它開啓了資料庫設計的更多可能性。
讓我們創建兩個資料表:cities 和 capitals。很自然地,首都(capitals)也是城市(cities),所以你希望有個方式,可以在列出所有城市時,同時也包含首都。如果你真的很清楚的話,你可以建立如下的結構:
這樣的查詢結果會是正確的,不過它有點不是很漂亮,當你需要更新一些資料的時候。
有一個更好的方法是這樣:
在這個例子中,captitals 繼承了 cities 的所有欄位(name, population, altitude)。欄位 name 的資料型別是文字型別(text),是一個 PostgreSQL 內建的資料型別,它允許字串長度是動態的。然後宣告 capitals 另外多一個欄位,state,以呈現它是屬於哪一個州。在 PostgreSQL,一個資料表可以繼承多個其他的資料格。
舉個例子,下面的查詢可以找出所有的城市名稱,包含各州的首都,而其海拔高過於 500 英呎以上:
回傳結果:
另一方面,下面的查詢可以列出非首都的城市,且其海拔在 500 英呎以上:
這裡的「ONLY」(cities之前),指的是這個查詢只要在資料表 cities 上就好,不包含繼承 cities 其他資料表。這裡許多我們都已經討論的指令 — SELECT、UPDATE、DELETE — 都支援 ONLY 這個修飾字。
雖然繼承經常被使用,但尚未整合唯一性限制或外部索引鍵的功能,這限制了它的可用性。詳情請參考 5.9 節的說明。
窗函數(window function)提供了在一個資料表中,進行資料列與資料列之間的關連運算。這部份可以和彙總函數的功能相呼應。然而,窗函數並無法像彙總函數一樣,把多個資料列運算合併為單一資料列的結果。取而代之的是,這些資料列仍然是分開並列的狀態。在這樣的情境下,窗函數能讓查詢結果的每一個資料列,都得到更多資訊。
這裡有一個列子,試著比較每一個員工他的薪資及他的部門平均薪資的情況:
前面三個欄位是由資料表 empsalary 直接取得,每一個資料列就是該資料表的每一個資料列列。而第四個欄位則呈現整個資料表中,與其 depname 相同的平均薪資。(這實際上就是由非窗函數的 avg 彙總而得,只是 OVER 修飾字讓它成為窗函數,透過「窗」的可見範圍做計算。)
窗函數都會使用 OVER 修飾字,然後緊接著窗函數及其參數。這是在語法上使其有別於一般函數或非窗函數的彙總。OVER 區段需要確切指出如何分組要被窗函數計算的資料列。PARTITION BY 在 OVER 中,意思是要以 PARTITION BY 之後的表示式來分組或拆分資料列的資料。對於每一個資料列而言,窗函數的結果是,透過所有和該資料列相同分組的資料,共同運算而得。
你也可以控制列被窗函數處理的次序,透過在 OVER 中加入 ORDER BY。(窗內的 ORDER BY 不見得需要對應到資料列輸出的次序)例子如下:
如上所示,rank 函數為每個有使用 ORDER BY 的分組,標記一系列數字的次序。rank 不需要特定的參數,因為它標記的範圍一定是整個 OVER 所涵蓋定的範圍。
窗函數所計算的範圍,是一個虛擬資料表的概念,是由 WHERE、GROUP BY、HAVING、或其他方式虛擬出來的。舉例來說,當某個資料列被 WHERE 過濾掉時,它也不會被任何窗函數看見。一個查詢中可以包含多個窗函數,透過不同 OVER 修飾字的指定,將資料做不同觀點的處理。但他們都會在一個相同的虛擬資料表中進行處理。
我們已經瞭解如果次序不重要的話, ORDER BY 可以被省略;且如果所有的資料列都只區分成一組的話,其實 PARITION BY 也可以省略。
還有另一個窗函數相關的重要概念:對於每一個資料列來說,它會在分組中還有個分組,另稱作窗框(window frame),有一些窗函數只對窗框裡的資料列進行處理,而不是整個分組。預設的情況是,如果 ORDER BY 被指定了,以 ORDER BY 排序後,那麼窗框的範圍就是從分組的第一列到該列為止,而在那之後資料列的值都會相同。當 ORDER BY 被省略的時候,預設窗框的範圍就是整個分組。下面是使用 sum 的例子:
上面可以看到,因為在 OVER 裡面沒有 ORDER BY,窗框就等於整個分組,甚至因為沒有 PARTITION BY,所以等於整個資料表。換句話說,每一個資料列總和都是整個資料表的總計,所以我們在每一個資料列中都得到相同的結果。但如果我們加入了 ORDER BY 之後,結果將會不同:
這裡的總和就是從第一筆(最小),加計到每一列,包含薪資相同的每一列(注意薪資相同的)。
窗函數只允許出現在 SELECT 的輸出列表及 ORDER BY 子句裡,在其他地方都是被禁止的,像是 GROUP BY,HAVING,WHERE等區段。這是因為窗函數在邏輯上,都是在他們處理完之後才進一步處理資料的。也就是說,窗函數是在非窗函數之後才執行的。這意指在窗函數中使用非窗函數是可以的,但反過來就不行了。
如果有一個需要在窗函數處理完再進行過濾或分組的查詢的話,你可以使用子查詢。舉列來說:
上面的查詢只會顯示內層查詢的次序(rank)小於 3 的資料。
當一個查詢使用了多個窗函數的話,它就會分別使用 OVER 子句來描述,但如果相同的分組方式要被多個函數所引用的話,就重覆了,也容易出錯。這種情況可以使用 WINDOW 子句來取一個別名,來取代 OVER。舉個例子:
交易(Transaction),是所有資料庫的基礎概念。基本上來說,一個交易指的是,一系列的執行步驟包裹在一起,其結果只有全部成功或全部失敗兩種情況的操作行為。而其即時的執行狀態,對於其他同時在進行的交易而言,相互之間都是不可見的。如果在執行過程中產生了錯誤而造成整個交易無法完成,那麼所有的指令都不會對資料庫原來的內容產生影響。
舉例來說,某個銀行資料庫存放著各個客戶的存款資訊,也存放著分行的存款總額資訊。假設我們想要轉帳 $100.00,從 Alice 的帳號轉到 Bob 的帳戶。可以很直觀地依敘述,直接以下列指令執行:
這些指令的細節在這裡並不重要,重要的是,有好幾個更新資料的動作要被執行。我們銀行的營業員需要保證所有的更新資料都要完成,或是保持原樣。如果因為系統錯誤,而造成 Bob 收到 $100.00,但 Alice 卻沒有轉出金額,就不是應該發生的事。又或是 Alice 轉出了現金,而 Bob 卻沒有轉入金額,她也不會是開心的客戶。我們需要具有保證交易安全的方法,也就是如果在執行過程中,有部份出了錯,那麼即使是已經執行的部份,也不會對資料庫產生影響。把這些更新資料的指令,包裝在一個交易之中,就是這個保證交易安全的方法。這樣的交易稱作為 atomic:從其他的交易的角度來看,整個行為只有完全執行,亦或是什麼都沒有做,兩種結果而已。
我們也希望有某個保證是,一旦某個交易被完成了,那麼會由資料庫系統發出通知,使它確實是永久性的資料,即使發生短暫的當機之後,資料也不會遺失。舉例來說,如果我們正在進行 Bob 的提款系統操作行為,在他走出銀行大門之後,我們不要有任何可能性使他的提款記錄消失。一個具備交易安全的資料庫,會將這裡交易裡的更新行為,在它們被回報完成之前,都記錄在長效型儲存裝置上(也就是磁碟機)。
交易安全資料庫的另一個重要性質是, atomic update 的概念:當多個交易同時在進行時,每一個交易都不能夠看到其他交易未完成交易的資料狀態。舉個例子,如果某個交易正在進行總計所有分行的餘額,它不會只包含 Alice 的分行的提款,或不計算 Bob 的分行的存款,反之亦然。所以交易必須是全有全無的結果,而不只是資料庫資料的永久性,還包含了交易執行過程的可視性。一個未完成的交易直到完全完成之前,其間資料的改變,對其他的交易而言都看不見;而當交易完成的同時,資料的改變也同時全部呈現出來。
在 PostgreSQL 中,所謂的交易,是以 SQL 的 BEGIN 及 COMMIT 兩個指令相夾的過程。 所以我們前述的銀行交易實際上會像這樣:
如果在交易的過程之中,我們決定不要完成交易(也許我們發現 Alice 的帳戶餘額不足),我們可以使用 ROLLBACK 指令來取代 COMMIT,那麼所有資料的變更都會取消。
PostgreSQL 一般將每一個 SQL 指令都視為一個交易來執行。如果你並沒有使用 BEGIN 指令,那麼每一個個別的指令就會隱含 BEGIN 先行,然後如果成功的話,COMMIT 也自動執行。一系列被 BEGIN 和 COMMIT 包夾的區域,有時候就稱為交易區塊。
有一些用戶端程式會自動加入執行 BEGIN 及 COMMIT 指令,使得你不需要要求就獲得交易區塊的效果。請詳閱你所所用的工具文件。
還有一種交易的控制更為細緻,就是使用交易儲存點(savepoint)。交易儲存點允許你可以選擇性地取消部份交易,而只成交剩下的部份。使用 SAVEPOINT 指令定義一個交易儲存點之後,你可以使用 ROLLBACK,回復該交易狀態到交易儲存點。所有在交易儲存點之後所造成的資料庫變更,都會被回復,但交易儲存點之前的變更會暫時留存。
在回復到交易儲存點之後,它仍然可以繼續進行,而你可以多次回到該儲存點。相反地,如果你確定你不要再回復到某個特定的交易儲存點時,它也可以被釋放出來,系統資源也可以獲得舒解。記得,釋放或回復到一個交易儲存點時,將會自動釋放所有在那之後的交易儲存點。
所有這些過程都發生在交易區塊之中,所有沒有任何改變會讓其他資料庫連線所發現。當你確認完成了交易區塊的時候,完成交易的動作就會讓其他的連線知道,也能發現資料的改變;同時,回復的動作也會再也無法執行了。
記得這個銀行的資料庫,假設我們從 Alice 的帳號提出了 $100.00,然後存入了 Bob 的帳戶之中,隨後又發現應該要存到 Wally 的帳戶。我們可以使用交易儲存點來完成這個過程:
當然,這個例子是過度於簡化了,但這呈現出在交易區塊中使用交易儲存點,有著更多的可能性。進一步來說,ROLLBACK TO 是唯一能夠控制交易區塊執行流程的方式,當系統產生錯誤時,可以縮小回復的範圍,而不是只能全部回復再執行。
這一章涵蓋了如何建立資料庫結構。在關連式資料庫中,原始資料儲存在表格之中,所以在這一章裡,主要說明表格如何建立及調整,以及有什麼樣的功能可以操控所存放的資料。再來我們會討論表格如何以結構來管理,以及權限的設定。最後,我們會簡短地看一下其他的功能如何影響資料儲存,像是繼承、表格分割、view、函數、還有觸發函數。
當你建立了一個表格,而你發現出了點錯,或者應用需求有一些改變,那麼你可以移除它再重新建立。但這可能不會一個好的選擇,當表格中已經儲存了許多資料時,或者表格正在被其他的資料庫物件所參考中(例如外部鍵參考)。所以 PostgreSQL 提供了一系列的指令來修改現存的表格。注意到這和更新表格內資料的概念是不同的:在這裡,我們主要針對的是調整表格的定義或結構。
你可以:
加入欄位
移除欄位
加入限制條件
移除限制條件
改變預設值
改變欄位資料型別
變更欄位名稱
變更表格名稱
所有這些動作都透過 ALTER TABLE 指令來進行,你可以參考該頁面取得詳細資訊。
要加入一個新欄位,請使用下面的指令:
這個新的欄位預設會以預設值填入(如果你沒有使用 DEFAULT 子句來宣告的話,那會使用 NULL)。
你也可以在新增同時建立限制條件:
事實上,所有在 CREATE TABLE 的選項都可以在這裡使用。要記得的是,預設值必須要符合限制條件的設定,否則這個欄位會無法加入。順帶一提的是,你也可以隨後再加入限制條件(隨後說明),在你更新好新的欄位資料內容後。
加入一個欄位,並且設定預設值,會更新表格的裡的每一個資料列(為了存入新的欄位內容)。然而,無預設值的話,PostgreSQL 就不會在實體上真正進行更新的動行。所以如果你的新欄位大多數的內容都不是預設值的話,那麼就建議不要在加入欄位時設定預設值。之後再使用 UPDATE 來分別更新其內容,然後再以隨後的介紹來更新預設值的設定。
要移除一個欄位,請使用下列指令:
不論資料在該欄位是否消滅,表格的限制條件都會同步再次啓動檢查。所以,如果欄位是被外部鍵所參考的話,PostgreSQL 不會就這樣移除它。你可以宣告同步刪去與此欄位相關的物件,加上 CASCADE:
請參閱 5.13 節,瞭解詳細的處理機制。
要加入限制條件,請使用表格限制條件的語法,例如:
要加入 NOT NULL 限制條件的話,就不能寫成表格的限制條件,請使用這樣的語法:
加入的限制條件會立即開始檢查,所以當下的資料內容必須要能符合條件才能加入成功。
要移除限制條件,你需要先知道它的名稱。如果你在宣告時有命名的話,那就使用那個名稱,否則你得找出系統自動命名的名稱。其所使用的指令為「\d tablename」,會列出表格相關的資訊。或使用其他的資料庫工具應該也可以找到它。找到之後請使用下列指令來移除限制條件:
(如果你的限制條件名稱像是「$2」這樣的,不要忘記使用雙引號括住,使其可以正確地被識別為是名稱。)
在移除欄位時,你需要加入 CASCADE,如果你需要同步移除相關的限制條件的話。像是外部鍵就會依賴另一個唯一性限制或主鍵的限制條件。
下面這可以用在移除 NOT NULL 限制的欄位:
(記得 NOT NULL 是沒有名稱的。)
要設定新的欄位預設值,請使用下面指令:
注意這並不會影響到已經存在的資料,只有隨後新增的資料才會使用。
要移除任何預設值,請使用:
這個指令會把預設值設為空值。因為預設值本來就設為空值,所以即使刪去一個未設定預設值欄位的預設值,也不會是一種錯誤。
要變更欄位成為另一個資料型別,請使用下列指令:
這只有在欄位內容可以被自動轉換型別時才會成功。如果存在比較複雜的轉換時,你需要加上 USING 子句來指示如何轉換資料內容。
PostgreSQL 會企圖轉換欄位預設值到任何新的型別,而所有的限制條件也會啓動檢查機制。但這些轉換可能會失敗,也可以產生意外的結果。比較好的作法是,先移除限制條件,再變更資料型別,最後再重新加入適當調整後的限制條件。
要變更某個欄位的名稱:
要變更表格的名稱:
當一個資料庫物件被建立時,它會先指定存取權限給擁有者,而擁有者一般來說就是執行建立指令的使用者。對大多數的資料庫物件來說,其預設的狀態就是只有擁有者(或超級使用者)可以對該物件進行所有操作。要讓給其他使用者來操作的話,就必須進行授權的動作。
有很多不同種類的權限:SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES、TRIGGER、CREATE、CONNECT、TEMPORARY、EXECUTE、USAGE。這些權限對於不同物件的效果,會因為是哪一種物件而有所差別(表格、函式...等等)。要瞭解完整在 PostgreSQL 中所支援的各種物件權限,請參考 GRANT 語法頁面。這裡的內容主要說明如何使用。
修改和移除一個資料庫物件,是只有擁有者才具備的權力。
要把一個物件被指派給一個新的擁有者的話,使用該物件的 ALTER 指令,例如:ALTER TABLE。超級使用者也可以做指派的動作;原來的擁有者如果它仍是該物件的管理群組一員的話,當然也可以;再來就管理群組新的成員。
要進行授權行為的話,請使用 GRANT 指令。舉例來說,如果 joe 是一個使用者,而 accounts 是一個表格,要讓他可以獲得更新表格資料的權力:
使用 ALL 的權限,就代表授權所有可設定的權限。
有一個特別的使用者是 PUBLIC,代表的是系統內的所有使用者。當資料庫內有很多使用者時,可以制定「群組(group)」來簡化管理。這部份詳細的說明請參閱第 21 章。
要移除權限,請使用 REVOKE 指令:
物件擁有者的特殊權限(例如DROP、GRANT、REVOKE...等)都是和擁有者一起設定,而無法單獨授權。不過,擁有者可以選擇移除自己的權限,例如建立一個唯讀的表格,讓自己和其他人一樣。
回到前面所說的,只有物件的擁有者(或超級使用者)可以變更該物件的權限。然而,也可以使用「with grant option」讓另一個使用者可以代授權給其他使用者。不過如果這個「grant option」被移除時,所有被代授權的使用者都會同時喪失該權限。更詳細的說明請參閱 GRANT 及 REVOKE 說明頁面。
每一個表格都有幾個系統欄位,而它們是由資料庫系統預先定義好的,所以使用者在定義欄位名稱時,不能使用這些名字。(這些限制並不是因為它們是保留關鍵字,所以就算用引號括起來也不能使用。)但在一般使用時,你也不需要特別考慮這些欄位,只要瞭解會有這些欄位存在就好。
oid
每一個資料列會有一個 Object ID,不過這個欄位只有在建立表格時,加上 WITH OIDS 語法才能使用。或者也可以藉由參數 default_with_oids 來切換使用。這個欄位的型別是 oid(和欄位名相同)。參閱 8.18 節瞭解詳細資訊。
tableoid
每個表格也有一個 ID 也會記錄在每一個資料列中。這個欄位特別方便在取得表格的繼承結構(參閱 5.9 節),如果沒有這個欄位的話,要去找出資料列的來源就會很麻煩。tableoid 可以參考 pg_class 表格中的 oid 欄位,進一步取得表格的名稱。
xmin
這指的是資料列在插入資料的版本資訊。(每一個資料列的版本,都是一個獨立的資料狀態;每一次資料的更新,都會在邏輯層產生一個新的資料列版本。)
cmin
指令識別碼,會存在於新增資料的交易中。(從 0 開始)
xmax
刪除資料的交易版本資訊,如果是 0 的話,代表讓資料列不是刪除中的資料列版本。這通常是用來指出某個刪除的交易還未被完成,或某個刪除正在被回復。
cmax
指令識別碼,有數字的話表示一個刪除的交易指令,或是 0。
ctid
表示每一個資料列存在於該表格的實體位址。注意到的是,雖然 ctid 可以用來快速找到特定的資料列版本,但 ctid 是會改變的,如果有執行過 VACUUM FULL 的話。所以 ctid 如果要用於固定的資料定位的話,是不應該被考慮的選項。OID 或額外自訂序列數字,更適合用於分別邏輯上的資料列。
OID 是一個 32 位元的數字,以 cluster 為單位配發。在一個大型或長期使用的資料庫中,是有可能出現重覆的情況。所以,假設 OID 是唯一的識別是不正確的觀念,除非你還有搭配其他方法來確保唯一性。如果你需要識別表格中的資料列的話,使用序列數產生器是比較建議的作法。OID 也可以這樣用來得到一些額外的預防性功能:
唯一性的限制應該設定在 OID 欄位上,來確保每一個 OID 可以識別每一個資料列。當有唯一性限制存在的時候,對於已經存在的資料列就不會有重覆的 OID。(當然,這方法只能用於資料筆數在 40 億筆以下的表格。不過實務上的表格多數都少於這個數目,而且太多資料的話,效果也會變得很差。)
OID 在多個表格間就不能假設為是唯一,你應該搭配 tableoid 來識別資料庫層級的唯一性。
當然,在建立表格時必須要加入 WITH OIDS 語法。在 PostgreSQL 8.1 之前,WITHOUT OIDS 是預設值。
交易識別碼也是 32 位元的數字。在一個長期運行的資料庫中,交易識別碼也可能會重覆。只要有適當的管理機制的話,這並不會是什麼嚴重的問題,詳情請參閱第 24 章。然而,長期來說(超過 10 億個交易),假定交易識別碼的唯一性是不明智的作法。
指令識別碼也是 32 位元的數字,其絕對上限是約 40 億個指令在一個交易當中,實務上這個限制並不會是問題。注意到這個限制是 SQL 指令數量的限制,而不是處理資料的限制。只有真正有改變資料庫內容的指令才會有指令識別碼。
除了透過 GRANT 指令設定 SQL 標準的權限系統之外,資料表也可以有資料列層級的安全原則,控制每個使用者在資料查詢或變更時,所能接觸到的資料列。這個功能就稱作資料列安全原則(Row-Level Security)。預設上,資料表並不會有這些安全原則,所以只要使用者能存取該資料表,就表示他能存取所有資料列的內容。
當資料列安全原則在資料表裡被啓動後(使用 ALTER TABLE ... ENABLE ROW LEVEL SECURITY),所有資料表的操作,就必須符合資料列安全原則的設定。(當然,資料表的擁有者並不受限於資料列安全原則。)如果資料表中未設定任何原則,那麼預設就是拒絕存取,意思就是任何資料列都不能被看見或修改。但如果是整個資料表的操作行為,像是 TRUNCATE 或 REFERENCES,就不會受到影響。
資料列安全原則可以被設定在命令,使用者角色,或兩者兼具。安全原則也可以使用 ALL 的修飾字,或具體指出是 SELECT、INSERT、UPDATE、或 DELETE。多重角色可以共用一個安全原則,一般使用者或承繼的角色都會被同步影響到。
要設定一個安全原則來指出哪些資料列可見或可修改,是以一個回傳值為布林值的表示式來決定的。這個表示式會計算每一個資料列的結果,在使用者進行任何操作之前。(這個規則唯一的例外是 leakproof 函數,用來確保沒有洩漏資訊;查詢最佳化元件會選押在確任資料列安全原則前就先執行它。)在這個表示式沒有回傳 true 的資料列,都是不能被存取的。獨立的表示式可用於提供資料列專屬的控制,判斷其是否可供讀取或修改。安全原則表示式是查詢的一部份,和使用者執行查詢時一起執行,不過,安全原則表示式是可以存取到該使用者看不到的資料。
超級使用者因為擁有 BYPASSRLS 的屬性,所以永遠可以通過安全原則檢查而存取資料表。資料表的擁有者一般來說也是可以通過檢查,但可以使用 ALTER TABLE ... FORCE ROW LEVEL SECURITY 來強制適用安全原則。
開啓或關閉資料列安全原則的權限,只屬於資料表擁有者。
使用 CREATE POLICY 指令來建立安全原則;使用 ALTER POLICY 指令來修改;使用 DROP POLICY 指令來移除原則。要開啓或關閉安全原則的功能,請使用 ALTER TABLE 指令。
每一個安全原則都有一個名稱,而一個資料表可以定義多個安全原則。安全原則是資料表專屬的,而每一個安全原則在所屬資料表內必須有一個唯一的名稱。不同的資料表下的安全原則可以取相同的名稱。
當多個安全原則使用者某個查詢上時,可能會使用 OR 串接(開放安全原則 permissive policies,這是預設的狀態),也可能以 AND 串接(嚴格安全原則 restrictive policies)。這類似角色授權的情況。有關於開放安全原則與嚴格安全原則的細節,稍後再進行說明。
先進行一個簡單的範例,我們建立一個安全原則在資料表 account 上,它只允許 managers 的使用者可以存取資料列,並且只能存取他自己帳號的資料列:
如果沒有指定角色或使用者時,就會以 PUBLIC 替代,也就是所有使用者都適用。要允許所有使用者存取他們自己的資料列的話,就可以簡化指令為:
想要定義一個安全原則是有別於可見性權限的話,請使用 WITH CHECK 字句。例如希望讓所有人都可以看到所有資料列,但只能修改自己的資料的話:
資料列安全原則也可以透過 ALTER TABLE 指令關閉。不過關閉資料列安全原則,並不會移除任何已定義的原則,只是單純被忽略而已。然後資料表的所有資料列,就只依標準 SQL 的權限系統,決定查詢及修改的權力。
下面是一個較複雜的例子,展示這個功能如何被應用於產品等級的環境裡。資料表 passwd 模擬 Unix 的密碼檔:
對於任何的安全設定,很重要的是,你必須實際測試來確認系統的行為和你預期的相同。使用上面的例子,下面的測試表現出權限設如預期地運作。
所有的安全原則,目前來說都是開放安全原則,意思是當有多個安全原則被引用時,它們會以 OR 運算串連其結果。開放安全原則用於只允許在計畫內的環境使用的話,它會比和嚴格安全原則(把安全原則用 AND 串連起來判斷)一起使用來得簡單。基於上面的列子,我們建立一個嚴格安全原則,它限制管理者只能透過 unix socket 連線才能存取 passwd 資料表:
我們接下來就可以看到,管理者透過一般網路連線,是看不到任何資料的,因為嚴格安全原則:
資料一致性的檢查,像是唯一性、主鍵、以及外部鍵參考,都會略過資料列安全原則,以維持資料的一致性。在發展資料庫結構時應該要特別小心,以資料列安全原則避免透過一致性檢查而產生隱藏通道洩露資訊。
在某些情況,很重要的是要確認安全原則是否被觸發。舉例來說,當進行資料備份流程時,如果安全原則造成某些資料被備份程式忽略了,那可能就會很糟糕。在這種情況下,你可以把 row_security 這個參數設為 off。這並不是避開安全原則,而是在觸發安全原則時,會出現錯誤訊息,使得我們可以發現進而修正原則。
在上面的例子裡,安全原則表示式只引用了目前資料列中的資料。這是最簡單也是最常見的形式,可以的話,最好以這樣的方式來設計安全原則。如果需要參考其他資料列或資料表來做決定的話,那麼可以使用子查詢或函數的方式達成,也就是包含一個 SELECT 的查詢語句在表示式中。要注意到的是,這種方法可能會造成資料庫內交易競爭(race condition)的狀態,不注意的話也可能產生資訊的洩漏。像這樣的例子,試試下面的資料表設計:
現在假設 alice 想要變更"slightly secret"的資訊,但決定不讓 mallory 看到新的內容,所以她這麼做:
看起來很安全,因為沒有窗口讓 mallory 可以看到"secret from mallory",然而,這裡就存在了交易競爭的情況。如果 mallory 也在同時做了:
因為她的交易是屬於 READ COMMITTED 模式,所以她有可能會看到"secret from mallory"。這會剛好發生在,她在 alice 的交易完成前一刻。mallory 的指令會暫時擋下 alice 的提交完成,而因為 FOR UPDATE,她會取得更新後的資訊。所以她並沒有從隱含的使用者執行 SELECT 取得資訊,因為子查詢沒有 FOR UPDATE,使得其他使用者可以從快照裡取得資訊。因為安全原則是以舊的 mallory 權限允許她看見該筆資料。
這個問題有好幾個面向的解決方式。一個簡單的方式就是使用 SELECT ... FOR SHARE 在安全原則的子查詢裡。但這樣就必須要讓使用者擁有 UPDATE 的權限,可能不太合適。(但也可以用另一個安全原則來做更多的限制,又或是把子查詢封裝進另一個安全的函數裡)同時,大量的引用查詢也可能造成效能的問題,特別是更新資料的時候。另一個解決辦法,如果參考的資料表並不是很常更新的話,那麼可以在資料表更新時強制鎖定該資料表,確保沒有其他交易能在同時進行查詢,也就不會洩漏任何資訊。或是等待其他所有交易都完成後,才提交更新變更新的安全方案。
更多詳細,請參閱 CREATE POLICY 和 ALTER TABLE。
PostgreSQL 實作了 SQL/MED 的部份標準,讓你可以存取不在 PostgreSQL 管理下的資料,重點是,你仍然只需要使用 SQL 語法。這樣的資料我們稱作為外部資料。(注意這部份的使用不要和外部鍵搞混了,外部鍵是資料庫內部的一種條件限制。)
外部資料的存取是透過「Foreign data wrapper」(外部資料封裝技術)。外部資料封裝技術是一組函式庫,用於和外部的資料源溝通,它封裝了資料連線和存取資料的細節。有一些外部資料封裝的套件收錄在 contrib 模組之中,參閱附件 F。其他種類的外部封裝套件則由第三方產品提供。如果沒有適合你的資料源的套件的話,你也可以自己寫一個,參閱第 56 章。
要存取外部資料,你需要建立外部服務物件,用它來連結特定的外部資料源,也可以對套件進行一些設定。然後你還需要建立幾個外部資料表,用於定義外部資料的資料結構。外部資料表的使用就如一般的表格一樣,只不過它沒有實際儲存任何資料罷了。當外部資料表被查詢時,PostgreSQL 會透過外部資料封裝套件,從外部資料源取得資料,或者傳送資料到外部,進行更新資料。
存取外部資料可能需要對外部資料源進行認證。這可以利用使用者映對(user mapping)的方法,讓每個 PostgreSQL 使用者在使用部資料表時,可以傳送自己的認證資訊。
進一步的資訊,請參閱 CREATE FOREIGN DATA WRAPPER、CREATE SERVER、CREATE USER MAPPING、CREATE FOREIGN TABLE、IMPORT FOREIGN SCHEMA 等內容。
欄位可以指定一個預設值。當新的列被插入,某些欄位卻沒有指定其值時,這些欄位將會被填入相對應的預設值。資料處理的過程中,當有欄位的值不確定時,也會被設定為其預設值。(關於資料處理的詳細內容,請參閱第 6 章。)
如果預設值並沒有明確被指定時,預設值就會是 null。一般來說空值是可接受的情況,因為空值可以表示「未知的資料」的意義。
在表格定義時,預設值接在資料型別後宣告,如下所示:
預設值也可以是運算表示式,會在資料插入的同時進行運算(不是在表格建立時)。常見的例子是 timestamp 欄位,會設定一個 CURRENT_TIMESTAMP 的預設值,使其在資料插入時設定為當下的時間。另一個例子是產生「序列數」,這在 PostgreSQL 中,通常以下列語法來表現:
這裡的 nextval() 函數會從序列物件取得下一個數字(參閱 9.16 節)。這個例子也常簡化為:
有關 SERIAL 的簡寫方式,將在 8.1.4 節中說明。
前一章討論了如何建立資料表和其他結構來保存資料。現在是把資料表填滿的時候了。本章介紹如何新增、更新和刪除資料表的資料。 下一章將會完整說明如何從資料庫中取回你遺落在裡面的資料。
「資料表」(table)在關連式資料庫中的角色很接近在紙上畫一個「資料表」:包含了列與欄。欄的數量與次序是固定的,而每個欄位都有一個名稱。列的數量是變動的—它表示在當下有多少資料被存在資料庫中。SQL 並不保證列在資料表中的次序。當讀取資料表的時候,除非明確要求要排序,不然列與列之間是不存在固定的次序。這些將在第 7 章中進一步說明。進一步來說,SQL 並沒有給每一列一個唯一性的識別,所以在資料表中是有可能存在有完全相同內容的列。這是 SQL 架構下的數學模型結果,通常不是理想的結果。在這章之後,我們會說明如何處理這個問題。
每一個欄位都有一個資料型別。資料型別限制了儲存於該欄位的資料內容,同時也設定了資料儲存的型態,使得該資料可以直接用於計算。舉個例子,一個被宣告為數字型別的欄位,就不能放進任何文字字串,而儲存於此欄位中的資料,可用於數學計算。相反地,一個被宣告為字元字串的欄位,可以儲存任何型能的資料,但就無法用於數學計算了,雖然也有其他操作可以進行字串串接。
PostgreSQL 擁有許多內建的資料型別,可以適應許多應用系統。使用者也可以自訂他們所需的資料型別。大多數內建的資料型別都有顯而易見的名稱與用法,所以我們打算在第 8 章再做詳細的說明。有一些常用的資料型別,像是 interger 用於整數,numeric 用於浮點數,text 用於字串,date 則是日期,time 是時間,而 timestamp 則同時包含日期和時間。
要建立一個資料表,你可以使用 CREATE TABLE 指令。這個指令你至少要指定一個名稱給新的資料表,還有每一個欄位的名稱與資料型別。例如:
這個建立一個叫作 my_first_table 的資料表,它包含了兩個欄位。第一個欄位叫作 first_column,其資料型別為 text;第二個欄位名稱為 second_column,資料型別為 integer。表格與欄位名稱的規則依 4.1.1 節中所介紹的識別字語法,但也有一些例外。注意欄位列表是用逗號分隔,並且包含於括號之中。
當然,前面的例子明顯只是做做樣子而已。一般來說,你會將你的資料表欄位以實際用途來命名,所以我們來看一下更實際的例子:
(numeric 資料型別可以儲存浮點數,用於典型的貨幣計量。)
小技巧當你建立了許多相關的資料表時,建立最好選擇一個用於命名表格及欄位的規則。舉例來說,有一個規則是使用單數或複數名詞來取名表格,兩者都有些人喜歡使用。
一個資料表中有多少欄位是有限制的,依欄位型別而定,上限通常是 250 個到 1600 個之間。不過,宣告到這麼多的欄位是非常罕見,而且應該是有問題的設定。
如果你不再需要某個資料表,你可以移除它。請使用 DROP TABLE 指令,如下所示:
企圖要移除一個不存在的資料表,會產生錯誤。不過,在 SQL 腳本中,在建立資料表前嘗試移除是很常見的,通常會忽略錯誤訊息,所以不論資料表是否已經存在,腳本都能如預期執行。(如果你需要的話,你也可以使用 DROP TABLE IF EXISTS 來避免產生錯誤訊息,但這並不是標準 SQL 語法。)
如果你需要變更資料表的結構的話,請參閱本章的 5.5 節。
到目前為止,你已經可以利用工具建立完整功能的資料表。本章接下來的部份會針對附加的功能介紹,像是確保資料完整性、安全性、或方便性。如果你現在急著要將資料存入你的資料表的話,你可以暫時跳過本章,到第 6 章繼續操作。
Schema 在台灣並沒有習慣的中文說法,所以仍使用原文,而不翻譯。
PostgreSQL 資料庫叢集(cluster)可以包含一個或多個資料庫。使用者和群組則是共用於叢集的層次,但沒有任何資料面是在資料庫之間能共用的。任何用戶端連到資料庫服務,都只能存取單一資料庫,你必須在連線時指定一個資料庫。
在叢集內的使用者並不需要對每個資料庫都有使用權。使用者共用指的是它們不能有同名的情況,例如在同一個叢集內,不能有兩個使用者名稱都叫 joe。但系統可以只允許 joe 使用某些叢集內的資料庫。
一個資料庫可以包含一個或多個 schema,它會包含一些資料表。Schema 也可以包含一些資料庫物件,像是資料型別、函數、和運算子。同樣的物件名稱在不同的 schema 中是不會衝突的。舉例來說,schema1 和 myschema 都可以擁有一個叫作 mytable 的資料表。和資料庫不同, schema 並不是完全隔離的:使用者可以直接取用他們連接的資料庫中的任何 schema,只要他們擁有足夠的權限。
使用 schema 有幾個好處:
允許多個使用者存取相同資料庫,而不會互相干擾。
將資料庫物件建立邏輯上的管理層,它們會更有彈性。
第三方的應用結構可以放在不同的 schema 中,避免有撞名的情況產生。
Schema 和作業系統裡的資料夾是類似的,只是它不能使用巢狀結構。
要建立 schema,請使用 CREATE SCHEMA 指令。給予一個自訂的名稱。例如:
要在 schema 中建立或存取某個物件,請使用句點(.)將兩者名稱串連起來:
這個形式在任何可以使用資料表的地方都是可以的,包含資料表結構更新指令,以及在接下來章節會討論到的資料處理指令。(我們只提到資料表的部份,但相同的概念用於其他資料庫物件都是一樣的,像是資料型別和函數。)
實際上,更一般化的語法是:
也可以這樣使用,但目前這只是為了符合 SQL 標準而已。如果你填上了資料庫的名稱,也必須填上你所連線的資料庫而已。
所以,要在新的 schema 中建立一個資料表,請使用:
要移除一個 schema,它必須要是空的,也就是所有所屬物件都已經被移除了,請使用:
但你也可以同步移除 schema 及其所屬物件,請使用:
這個部份的機制請參閱 5.13 節,會深入介紹移除時的問題。
通常你會想要建立一個 schema 給某個使用者使用(這是一種藉由命名空間規畫來限制使用者權限的方法)。可以使用下列語法:
你甚至可以省略 schema 名稱,省略的話,schema 名稱會與使用者名稱相同。請參閱後續的 5.8.6 節來瞭解如何使用。
Schema 名稱以「pg_」開頭的,是系統的保留名稱,使用者不能使用這樣的名稱建立 schema。
在前面我們所建立的資料表都沒有指定 schema 名稱。預設使用的 schema 是「public」,每一個資料庫都會有這個 schema。所以,下面兩種寫法是一樣的:
以及:
完整的名稱寫法是冗長而不容易使用的,通常最好不要把一些特別的 schema 名稱寫到應用程式裡。而資料表時常是以簡要的寫法引用,也就是只寫資料表本身的名稱。資料庫系統依據搜尋路徑的規則找到該資料表。在搜尋路徑上所遇到的第一個資料表就會被使用。如果整個搜尋路徑走完都沒有符合的資料表,那麼才會回報錯誤,即使該資料表名稱有出現在資料庫裡的其他 schema 中。
第一個會被搜尋的 schema,就是目前的 schema。除此之外也用於新的資料表建立,當 CREATE TABLE 未指定 schema 名稱的話,也會依搜尋路徑的 schema 建立。
要顯示目前的搜尋路徑,請使用下面的指令:
預設的情況是:
第一個項目指的就是和目前使用者同名的 schema 會被使用,而如果沒有同名的,它就會被忽略。第二個項目則是先前介紹過的公開 schema。第一個被找到的 schema,就會是新建物件時預設的位置,這就是為什麼預設都會被建立在公開的 schema。當某個物件在使用(資料表結構調整、資料更新、或查詢指令)時沒有註明 schema 的話,那也會使用搜尋路徑來找到符合的物件。不過,預設上只會搜尋公開的 schema。
要設定新的搜尋路徑,請使用:
(我們在這邊暫時忽略掉 $user,因為還沒有立即性的需要。)然後我們就可以試著存取資料表而不用加上 schema:
因為 myschema 在搜尋路徑裡是第一個項目,所以新的物件就會被建立在該處。
我們也可以這樣寫:
這樣的話,不指定的話就不再能夠再使用公開的 schema 了。「public」schema 並沒有比較特別,除了它一開始就會存在之外,它也可以被移除。
請參閱 9.25 節,將會介紹其他設定 schema 搜尋路徑的方式。
搜尋路徑也用於資料型別、函數、及運算子的搜尋,就如同在資料表上的行為一樣。資料型別和函數名稱完整的寫法也和資料表相同。如果你需要特別指出運算子的完整路徑的話,它比較特別,你必須這樣寫:
這是為了避免語法上的混淆。如下所示:
實務上我們都還是依賴路徑搜尋來使用運算子,這樣可以避免使用冗長且低可讀性的程式碼。
預設的情況,使用者無法存取任何不屬於他們的 schema 中的物件。要允許存取的話,該 schema 的擁有者必須要授予 USAGE 權限給其他使用者。要允許其他使用者使用某個 schema 中的物件,通常需要額外給予適當的權限。
使用者想要在其他使用者的 schema 中建立新物件的話,就必須要授予 CREATE 的權限。注意,預設上,所有的使用者在 public schema 中,都具備 CREATE 和 USAGE 權限。這使得所有的使用者在連線到某個資料庫之後,就可以在 public schema 上新增物件。如果你不希望這樣,你可以移除這些權限:
前面的「public」指的是 schema,是一個物件識別器;而後面的「PUBLIC」指的是所有使用者,是一個關鍵字。所以使用不同的大小寫,可以再複習 4.1.1 節的內容。
除了 public 以及使用者自行建立的 schema 之外,每一個資料庫還有一個稱作 pg_catalog 的 schema,它包含了系統資訊的資料表和內建的資料型別、函數、及運算子。 pg_catlog 永遠都都是搜尋路徑裡的有效項目。它沒有明確地顯示在搜尋路徑裡,但卻是隱含優先搜尋,在那些明定的搜尋項目之前。這是為了確保內建的物件的名稱都能被找到。然而,你可以把 pg_catlog 放在搜尋路徑的最後面,如果你希望自訂的同名物件能優先被使用的話。
系統用的資料表都以「pg_」開頭,為的就是確保不會有衝突的情況出現,以免將來新的系統資料表和你現在所定義的資料表同名。(以預設的搜尋路徑來說,一個簡單的資料表使用,會直接被同名的系統資料表取代。)系統資料表會一直遵循這個命名規則,就不會產生衝突,只要使用者不使用「 pg_」開頭的命名方式就好了。
Schema 可以在許多方面協助你組織你的資料。有一些巧妙的樣版值得推薦,也很方便以預設的方式支援:
如果你沒有建立任何 schema 的話,那麼所有使用者就是隱含著都使用 public schema。這種情況指的是都沒有設定任何 schema,而主要推薦給在一個資料庫中,只有一個使用者的情況。這樣的樣版設定也適合之後轉換到無 schema 設計的資料庫環境。
你可以為每一個使用者建立一個同名的 schema。回想一下先前介紹的預設搜尋路徑,第一個項目就是 $user,表示該使用者的名稱。所以,每一個使用者有一個專屬的 schema,預設上,他們就只存取他們所擁有的 schema。 如果你使用這個情境樣版,你也許會需要移除 public schema 的權限,甚至直接移除它,讓使用者真正被隔離在他們自己的 schema 中。
要安裝共享的應用程式(每個人共享資料表,有一些第三方提供的延伸套件,或其他的東西。),把他們放到不同的 schema 裡,然後記得要設定好適當的存取權限。使用者可以使用完整的名稱來存取這些共享的應用程式,或把他們加入到搜尋路徑中,由使用者自己來決定。
在標準 SQL 中,在同一個 schema 中的物件,分別被不同使用者擁有,是不被允許的。然而,有一些實作系統甚至不允許使用者建立和自己不同名的 schema。事實上,schema 和使用者的概念,對於只支援基本 schema 的資料庫系統本身而言,幾乎是相同的。所以,許多使用者會認為完整名稱指的是 user_name.table_name。這也就是為什麼 PostgreSQL 建議你這樣為每一個使用者建立他們同名的 schema。
再者,在標準 SQL 裡,也沒有所謂 public schema 的概念。極致相容標準的話,你就不應該使用,或移除 public schema。
當然,也有些 SQL 資料庫並沒有實作 schema,或提供其他跨資料庫存取的命名方式。如果你需要和這些系統共同運作,要提高可攜性的方式就是不要使用任何 schema。
到目前為止,我們已經解釋瞭如何將資料新增到資料表以及如何更新資料了。剩下的就是討論如何刪除不再需要的資料。 正如新增資料時只能新增整個資料列一樣,你只能從資料表中以資料列為單位刪除資料。在前面的章節中,我們解釋了SQL沒有提供直接處理某個資料列的方法。因此,只能透過指定要刪除的行必須符合的條件來刪除指定的資料列。如果資料列中有主鍵,則可以指定確切的資料列。但是,你也可以刪除全部符合條件的資料列,更可以一次刪除資料表中的所有資料列。
您使用 DELETE 指令刪除資料列;該語法與 UPDATE 指令十分類似。例如,要從產品表中刪除價格為 10 的所有資料列,請使用:
如果你只是寫:
那麼資料表中的所有資料列都將被刪除! 請程式設計師一定要小心使用。
PostgreSQL 支援基礎的分割資料表。本節描述如何讓分割資料表成為資料庫設計的一部份。
資料表的分割,指的是把一個邏輯上很大的資料表,分割為數個實體的小資料表。分割資料表可以獲得幾點好處:
資料查詢的效能在某些情況下會大幅改善,特別是資料表中有一些資料列是時常被存取的,而它們只存在於某一個單一的分割區,或某一小群分割區。分割資料表的優勢在於大幅降低欄位索引的大小,而當其大小縮小到可以完全在記憶體中執行時,那就會獲得相當大的效能改善。
當資料查詢或更新時,它可能牽連到某一分割區大部份的資料列,效能同樣會獲得改善,它可以直接掃描存取整個「小」區域,而不是在「大」資料表中,以索引逐筆搜尋分散的資料列。
大量載入或移除資料的話,可以直接對整個分割區操作,當然這些資料要能符合分割資料表的設計。使用 ALTER TABLE DETACH PARTITION 或是 DROP TABLE 移除特定的分割資料表,都比進行大量的 DELETE 要快非常多。因為這些指令不會進行資料表的整理,而大量的 DELETE 會引發 VACUUM 的啓動。
少用的資料可以搬到較便宜或比較慢的儲存媒體。
這些優勢通常是在原來資料表特別大是會很明顯,不過實際上會獲得什麼樣的改善,還是要視應用程式而定。一個基本的概念是資料表的大小,如果超過了資料庫主機的記憶體上限,那就最好進行資料表的分割。
PostgreSQL 內建提供的資料表分割方式:
Range Partitioning
資料表是以某個欄位或某些欄位的資料內容範圍來分割,所謂的範圍,就表示彼此之間沒有重疊的部份。舉例來說,你可以以資料的範圍做分割,或是以指定的公司資料 ID 的範圍來分割。
List Partitioning
明確列出有哪些資料的值要被分配在哪些資料表。
如果你的應用需要使用上述兩種以外的分割方式,還有其他方式,像是繼承,UNION ALL views,也可以使用。這些方式提供更多的彈性,但都不如內建分割方式所提升的效能。
PostgreSQL 提供一個方式,可以指定如何將資料表分割為較小的資料表,這些小資料表稱作為分割區(partitions)。被分割的資料表,稱作分割資料表。分割主鍵包含了分割方法與一些欄位內容或是表示式。
所有新插入的資料列將會依分割主鍵的規則,轉送至分割區中。每一個分割區都是所有資料列的子集合,範圍由其定義的資料邊界而定。目前支援的分割方法有 Range 及 List 分割法,也就是每一個分割區都需要指定一個區段或是一個列表。
分割區本身也可以是分割資料表,這稱作為次分割(sub-partitioning)。分割區會擁有它們自己的索引,限制條件,以及預設值,是獨立於其他分割區的。索引必須要分別為每個分割區建立。請參閱 CREATE TABLE 進一步瞭解建立分割資料表及分割區的指令。
一般資料表和分割資料表是無法互相轉換的,但你可以使一個已存放資料的一般資料表或分割資料表成為某個分割資料表的新分割區;或是從某個分割資料表移出某個分割區,使其成為獨立的一般資料表。請參閱 ALTER TABLE 瞭解 ATTACH PARTITION 及 DETACH PARTITION 的使用方式。
分割資料表和個別的分割區之間,隱含著繼承的關係;不過它們並無法使用先前章節所介紹過的繼承功能。舉例來說,分割區不能同時是其他分割資料表的子資料表,一般資料表也不能繼承分割資料表。簡單來說,分割資料表及其分割區,都不能和一般資料表有任何繼承的關係。分割區與分割資料表是階層關係,而其分割區也是繼承的階層,所以所有一般的繼承規則,在 5.9 節中介紹的,都會成立,除了有一些例外,比較重要的如下:
分割資料表的 CHECK 及 NOT NULL 限制條件,會被其分割區所繼承。 在分割資料區中,把 CHECK 標示為 NO INHERIT 是不被允許的。
在分割資料表新增或移除限制條件時使用 ONLY 的話,只有在其還沒有分割區時是允許的。一旦其下有分割區存在,使用 ONLY 就會產生錯誤。換句話說,當有分割區時,這個執行方式是不被允許的。但是你可以新增或移除分割區裡的限制條件,只要它們並沒有在分割資料表中存在就好。在分割資料表嘗試執行 TRUNCATE ONLY 指令,也會產生錯誤,因為分割資料表並未實際存放資料。
分割區不能有分割資料表裡沒有的欄位。不能在 CREATE TABLE 時建立,也不能使用 ALTER TABLE 增加。資料表能成為一個分割區,它的欄位必須和分割資料表完全吻全,包含 OIDs。
你無法移除分割區中的 NOT NULL 限制條件,如果它是定義在分割資料表中的話。
分割區可以是外部資料表(參閱 CREATE FOREIGN TABLE),雖然它會有一些使用上的限制。舉例來說,插入資料到分割資料表,資料並不會轉送到外部資料表的分割區處理。
假設我們為一家大型冰淇淋公司建構一個資料庫。這家公司每天測量最高溫度,同時也統計各區域的銷售情況。概念上,我們需要像這樣的資料表:
我們知道大多數都是在進行近期的資料查詢,如最近一週、最近一個月、或最近一季的資料,這個資料表用於產生管理用的線上報表之用。為了降低需要儲存的資料量,我們決定只保存 3 年內有價值的資料。每一個月開始時,我們就會移除最舊那個月的資料。在這種情況下,我們可以使用分割資料表來幫助我們滿足所有需求。
在這個例子中,使用下列步驟來宣告分割資料表:
建立 measurement 資料表時,使用 PARTITION BY 子句,在本例子使用 RANGE 的分割方法,然後以 logdate 作為分割主鍵。
你也可以使用多個欄位作為分割主鍵來依範圍分割,當然,這會產生相當多的分割區,它可以分割得更小一些。也就是說,使用較少的分割主鍵欄位,是較為粗略的分割。當分割資料表被查詢時,就可以減少分割區存取的數量,如果條件是遍及數個欄位時。舉例來說,可以想像一下一個以範圍分割的資料表,同時以 lastname 及 firstname 兩個欄位作為分割主鍵的情況。
建立分割區時,每一個分割區的定義都必須指定其分割方式的規則與分割主鍵。需要注意的是,如果指定的規則,造成某些分割主鍵的值會落在多個分割區中的話,將會產生錯誤。從分割資料表插入資料時,如果沒有對應到任何一個分割區的話,也會產生錯誤;適當擺放資料的分割區必須要手動加入。
分割區的建立就如同一般的 PostgreSQL 資料表一樣(也可以是外部資料表),也可以指定各自的 tablespace 和儲存參數。
不需要為分割規則設定分割區的限制條件,而是在設定分割方式及規則時,其限制條件就已經隱含在內了。
要實現子分割時,使用 PARTITION BY 子句來建立個別的分割區。舉例來說:
在建立了 measurement_y__2006m02 資料表之後,所有新增到 measurement 資料表中符合分割規則而被派送到 measurementy_2006m02 的資料(或是符合條件的資料直接新增到 measurement_y2006m02),都會再進一步依據 peaktemp 欄位的內容轉存到它的子分割區。這個分割主鍵是可以和其父資料表分割主鍵有重疊的,不過要注意的是,指定子分割區的規則時,資料真的會分配到該子分割區,資料庫系統不會去檢查該分配是不是真的會發生。
為每一個分割區資料表的分割主鍵建立索引。(這並不是一定要做的事,不過對大多數的情況是好的。如果你需要這些值俱備唯一性,那你應該建立唯一索引或是主鍵。)
確定 postgresql.conf 中的 constrain_exclusion 設定並未被關閉。如果是關閉狀態的話,查詢最佳化就不會進行。
在上面的例子中,我們需要每個月建立一個分割區,所以如果能再有程序自動建立這些資料表就更好了。
一般來說,分割區在初始建立時,會假設其會不斷地變動。通常會需要定期移除舊的分割區,然後為新的資料加入新的分割區。使用分割資料表時,其中一件很重要的事,就是要能夠很明確地做到這個管理動作,否則大量地實體資料變更,會嚴重拖累資料庫系統的效率。
最簡易移除資料的方式,就是移除分割區:
這可以非常快地移除數百萬筆資料,因為它並不是單獨去移除每一筆資料。注意到的是,這個動作需要父資料表取得 ACCESS EXCLUSIVE 的鎖定。
另一個方式也很常使用,就是把某個分割區從分割資料表中卸載,但仍然保存該分割區的資料表:
這樣可以在資料被移除之前再進行一些其他的操作。舉例來說,很常見的使用情況是備份資料,利用 COPY 指令、pg_dump、或相關的工具;把資料以小單位進行彙總計算產生報表,也是很常用的方式。
接下來,要處理新的資料也是類似的動作,我們可以建立新的資料表,並宣告為分割區來使用,就如同先前我們介紹的設定方式一樣:
另一種更方便的方式是先建立新的資料表,然後再將它掛載為分割區。好處是這樣可以在掛載前先進行資料的載入、檢查和轉換:
在進行 ATTACH PARTITION 指令前,建議最好先設定 CHECK 限制條件,同分割資料表的條件,這樣的話,系統就會跳過隱含的資料檢查過程。如果沒有先設定限制條件的話,資料表會被 ACCESS EXCLUSIVE 鎖定,然後進行全資料掃描以檢查其合法性。最後我們在掛載分割區之後再移除該 CHECK 設定,因為它已經不再需要了。
使用分割資料表是會有下面的受限制的使用情況:
沒有方法可以自動在所有分割區建立需要的索引。每個分割區的索引都需要個別建立。這也代表了,沒有任何方式可以建立主鍵、唯一性限制條件、或其他跨分割區的限制條件需求;只能個別分割區自行維護。
因為分割資料表無法建立主鍵,所以外部鍵就無法支援了,無論是參考其他資料表或被參考,都不支援。
在分割資料表使用 ON CONFLICT 子句的話,會產生錯誤訊息,因為沒有唯一性及除外限制可以使用。目前不支援跨所有分割區的唯一性限制,也包含其他除外限制。
想要利用 UPDATE 改變欄位值,使資料移動到另一個分割區是行不通的。因為隱含的資料限制條件會造成其更新失敗。
資料列的事件觸發函數,必須定義在個別分割區的資料表中,而非分割資料表。
使用內建的分割資料表,基本上適用於大多數的應用情境,也可以使用一些彈性的技巧會更有幫助。分割資料庫也可以用資料表繼承的方式來達成,好處是可以支援一些本來有限制的使用情況,例如:
分割資料表會強制使所有分割區都必須要與父資料表完全一樣的資料結構,但使用繼承的話,就可以允許分割區各自擁有額外的資料欄位。
資料表的繼承可以是多重繼承。
內建的分割資料表只支援列表(list)和範圍(range)兩種資料對應方式,而繼承則可以用自訂的方式來對應資料分區。(注意,如果你的資料對應方式無法適當地利用每個分割區的話,那麼查詢將會很沒有效率。)
內建的分割資料表相對於資料表繼承時,有一些操作需要較嚴格的資料鎖定(lock)。舉例來說,分割資料表在新增或移除分割區時,會使用 ACCESS EXCLUSIVE 等級的資料鎖定,但實際上在資料表繼承維護時,只需要 SHARE UPDATE EXCLUSIVE 等級即可。
以先前使用過的 measurement 資料表作為範例說明,我們要使用繼承功能來完成分割資料表。請參考下列步驟:
建立主資料表(master),所有的分割區將會繼承它,而這個資料表不會儲存任何資料。請不要在這個資料表上定義任何限制條件,除非你希望每一個分割區都要有相等的限制條件。同樣地,也不要定義任何索引或唯一性限制。在這個例子裡,資料表 measurement 就如同先前一開始宣告的一樣。
建立幾個子資料表(child),由主資料表繼承而得。一般來說,這些資料表並不增加額多的欄位。就如同內建的分割資料表一樣,這些子資料表就是一般的 PostgreSQL 資料表(或是外部資料表)。
在每個子資料表(分割區)中,加入明確分隔的欄位值限制條件。
典型的範例如下:
請確認這些限制條件是明確的且彼此不會重疊的。下面是使用範圍分割時常見的錯誤:
這裡的錯誤來自於「200」同時符合兩個分割區的條件。
下面是比較好的寫法:
對每一個分割區,對分割主鍵欄位建立索引,就如同一般的索引建立一樣。
我們希望應用程式可以使用 INSERT INTO measurement ...
的語法,資料則自動轉送到適當的資料表。我們可以在主資料表建立適當的 Trigger 來完成此事。如果資料都會被新增到最新的子資料表中,我們可以建立很簡單的事件觸發函數:
建立這個函數之後,再建立 Trigger:
我們必須每個月都重新定義這個函數,使其都指向最新的分割區,但 Trigger 宣告並不需要更新。
我們也可以在新增資料時,讓它們自動找到適當的分割區,那就需要宣告一個比較複雜的函數,如下:
Trigger 本身的定義仍然是一樣的。要注意的是,每一個 IF 判斷式,都必須要完全符合 CHECK 限制條件的宣告。
這個函數比前一個函數要複雜許多,但它就不需要時常更新了,只要分割區在需要前就被建立就好。
實務上,最好是可以先檢查新建立的分割區,在它要掛載之前。簡化來看,我們在這個例子中使用事件觸發函數(Trigger)來處理這個動作。
另一個作法是在主要的資料表上設定規則,來取代事件觸發函數。例如:
基本上,設定規則對資料庫的負擔是比事件觸發函數更重一點,但其負擔是在於每一次查詢,而非每一個資料列,所以這個方式比較適合一次大量插入資料的情況。不過,在大多數的情況,事件觸發函數會有比較好的效能。
但要注意的是 COPY 指令會忽略規則。如果你要使用 COPY 來插入資料,你應該要從父資料表插入。而 COPY 會觸發事件觸發函數,所以你如果使用 Trigger 的話,那就像一般使用的方式使用就好了。
另一個使用 rule 的缺點是,沒有比較簡單的方法可以強制產生錯誤,如果設定的規則錯誤的話;那些出錯的資料,只會靜靜地留在父資料表中而已。
確認一下 postgresql.conf 中的 constraint_exclusion 並沒有被關閉。如果被關閉的話,查詢就不會最佳化處理。
就如同我們看到的,複雜的分割區結構,可能會需要相當數量的 DDL 宣告。在先前的例子,我們每個月建立一個新的分割區,所以比較聰明的作法是寫一小段程式來自動產生那些指令。
要快速刪除舊資料,可以簡單地移除不再使用的分割區資料表即可:
將一個分割區從分割資料表中卸載,仍然留存該資料表:
要新增一個分割區來處理新的資料,建立一個空的分割區,就如同先前介紹的方式:
另一種更方便的方式是先建立新的資料表,然後再將它掛載為分割區。好處是這樣可以在掛載前先進行資料的載入、檢查和轉換:
如果你使用繼承在實現分割資料表的話,請注意下列項目:
沒有任何自動的方式可以檢驗 CHECK 子句之間是否矛盾。比較建議的作法是程式化控制分割區的建立和維護,而非手動處理。
在這裡所展示的方法都是假設分割主鍵欄位不會改變,也不會需要把某個資料列在分割區間移動。如果你企圖使用 UPDATE 指令,而期待資料列自動移到另一個分割區的話,那將會得到失敗的結果,因為會先被 CHECK 限制條件擋下來。如果你需要做到這樣的效果,那麼你可以建立 UPDATE 事件的觸發函數,但這可能會造成你的資料庫管理更加複雜。
如果你手動執行 VACUUM 或 ANALYZE 指令,不要忘了你需要在每個分割區資料表分別執行。
例如:ANALYZE measurement;
將只會在父資料表執行。
INSERT 指令裡的 ON CONFLICT 子句將無法運作,因為它只能在父資料表產生作用,而不會到子資料表中執行。
事件觸發函數(Trigger)需要建立,負責把資料放在設計好的資料表中,除非應用程式很清楚分割區的結構。事件觸發函數可能會不太好寫,而且也會比使用內建的分割資料表時慢很多。
除外限制(Constraint exclusion)是一種查詢最佳化的技術,用來改善分割資料表的效能。(包含內建分割資料表的方式,以及繼承式的分割資料表)舉個例子如下:
如果沒有除外限制的話,上面的查詢語句將會掃描每一個 measurement 資料表的分割區。而開啓了除外限制的話,查詢前就會先測試限制條件,確認該分割區是否需要掃描,因為有些分割區可能完全沒有資料符合該條件。如果確實有不需要掃描的分割區,那麼它就會在實際查詢時排除在外。
你可以使用 EXPLAIN 指令來比較除外查詢開啓與否的差異。下面是未最佳化的例子:
可以看到有些分割區可能會使用索引掃描來取代全資料表掃描,但這裡的重點是,有些分割區是完全不需要掃描的。當我們開啓除外限制時,很明顯可以得到一個更簡潔的查詢計畫:
要注意的是,除外限制只檢查 CHECK 子句,而不是索引,所以不一定要對主鍵欄位定義索引。索引是否需要在分割區建立,是依據你希望查詢在該分割區大範圍或小範圍被查詢。索引的用處在後者會比較明顯,而不是前者。預設也是建議的選項不是 on 也不是 off,而是使用 partition 子句,讓查詢只在需要執行的分割區執行。設定除外限制為「on」的話,對於大範圍的查詢很有用,但簡單查詢就不見得有好處了。
下面還有幾點注意事項,繼承和分割資料表都適用:
除外限制只適用於 WHERE 子句是常數的條件(或外部引用的參數)。舉例來說,和一個不確定結果的函數比較的話,如 CURRENT_TIMESTAMP,那就無法最佳化,因為查詢計畫無法事先得知執行時的值。
保持分割區限制條件簡潔一些,否則查詢計畫無從查驗該分割區是否需要處理。請在列舉分割時,使用簡單的等式;或在範圍分割時使用簡單的比較式,就如同先前的例子一樣。一個好的規則是只包含分割主鍵的欄位,並且使用 B-tree 可以索引的運算子,也同時宣告在主資料表中,只允許適用於 B-tree 的欄位宣告為分割主鍵。(如果使用內建分割語法的話,這不會有什麼問題,因為系統會自動宣告適合查詢計畫的限制條件。)
由於除外限制會在查詢前檢查所有分割區的限制條件,所以大量的分割區可能會增加查詢計畫的時間。所謂的「大量」,通常幾百個分割區還是可以接受的範圍,但最好不要用於上千個分割區的情境中。
前面的章節解釋了如何建立資料表,如何填入資料以及如何操作這些資料。現在我們是時候討論如何從資料庫中檢索資料了。
表格是關連式資料庫結構裡的主要物件,因為它負責存放資料,但並不是資料庫中唯一的物件。還有許多其他種的物件存在,讓使用上更方便或管理更有效率。這些其他的物件並不在本章中討論,但我們先在這裡列出讓你知道:
視觀
函數與運算子
資料型別和領域
觸發事件和規則覆寫
關於這些物件的詳細說明安排在。
有時在修改資料列的操作過程中取得資料是很方便的。INSERT、UPDATE 和 DELETE 指令都有一個選擇性的RETURNING 子句來支持這個功能。使用 RETURNING 可以避免執行額外的資料庫查詢來收集資料,特別是在難以可靠地識別修改的資料列時尤其有用。
RETURNING 子句允許的語法與 SELECT 指令的輸出列表相同(詳見)。它可以包含命令目標資料表的欄位名稱,或者包含使用這些欄位的表示式。常用的簡寫形式是 RETURNING *,預設是資料表的所有欄位,且相同次序。
在 INSERT 中,可用於 RETURNING 的資料是新增的資料列。這在一般的資料新增中並不是很有用,因為它只會重複用戶端所提供的資料。但如果是計算過的預設值就會非常方便。 例如,當使用串列欄位()提供唯一識別時,RETURNING 可以回傳分配給新資料列的 ID:
對於 INSERT ... SELECT,RETURNING 子句也非常有用。
在 UPDATE 中,可用於 RETURNING 的資料是被修改的資料列新內容。例如:
在 DELETE 中,可用於 RETURNING 的資料是已刪除資料列的內容。例如:
如果目標資料表上有觸發函數的話(),則可用於 RETURNING 的資料是由該觸發函數所修改的資料列。因此,由觸發函數計算檢查欄位是 RETURNING 的另一個常見用法。
資料型別是一種限制資料如何被儲存在表格中的方式。然而,對許多應用來說,這樣的限制還是不夠細膩。舉個例子,一個欄位包含了產品價格,當然它必須只能是正整數,但並沒有標準的資料型別可以只限制在正整數。另一個需求是,你可能想要限制的條件是依據其他的資料而定。舉例來說,在表格中的產品資訊,每一個產品編號都不能重覆。
所以,SQL 允許你在表格和欄位上定義額外的限制條件,它幫助你對資料有更多的控制能力。當某個使用者輸入資料時,違反了限制條件,錯誤訊息就會產生。這些限制條件也會限制預設值的設定。
使用 CHECK 是最普遍的限制條件製定方式,它可以允許你指定某個欄位必須符合某個布林條件式的判斷。舉個例子,要滿足產品價格是正數的話,你可以使用這樣的語法:
如同你所看到的,限制條件會接在資料型別之後,就像是預設值的設定一樣。預設值和限制條件的設定,在語法撰寫上沒有先後次序。檢查限制條件使用關鍵字 CHECK,然後接著是一組以括號括起來的條件式。其條件式應該要包含被限制的欄位,不然就沒有任何意義。
你也可以讓該限制條件擁有另一個名稱,這樣的好處是,當錯誤訊息發生時,你可以明確得到是哪一個限制被違反了:
如上,給予這個限制條件一個名稱,使用關鍵字 CONSTRAINT,緊接著一個限制條件的定義。(如果你沒有自行命名,系統也會自動取一個名字)
一個限制條件可以參考多個欄位。例如你設定了標準價格和優惠價格,而你需要確保優惠價格一定是比標準價格要便宜的話:
前兩個限制條件和前述很類似,而第三個是新的語法。它並不是只參考某個特定的欄位,而是以逗號分隔列出所有需要遵守的條件。欄位的定義和限制條件的定義,撰寫上沒有規定次序。
我們會說前兩個是欄位的限制,而第三個是表格的限制,因為它是獨立於其他的欄位定義的。欄位限制也可以寫成表格的限制方式,不過反過來通常就不行,因為一個欄位的限制,指的就是只參考到語法上它所接續的欄位而已。(PostgreSQL 並沒有強制這樣做,但如果你的語法與其他資料庫共用的話,最好還是依這樣的語法避免混用。)上面的例子也可以改寫成如此:
或等同於:
都可以照你所喜愛的語法撰寫。
命名表格的限制條件和欄位限制條件的命名是一樣的:
應該要注意的是,檢查限制條件是否成立,端看條件表示式在運算後是真值(true)還是空值(null)。因為當有運算元是空值時,多數的運算結果都是空值,所以可能會有空值產生在想要限制條件的欄位之中。要確保欄位中不會出現空值的話,請參閱下一段的說明。
限制無空值只要以下方的語法設定,就可以限制欄位不得存在空值的輸入:
限制無空值的語法,只能使用在欄位限制上。而限制無空值等效於以 CHECK 建立一個限制條件式為(IS NOT NULL),但在 PostgreSQL 明確使用 NOT NULL 語法的話,處理會更快速。只是它的缺點是你無法給予這樣的限制一個自訂的名稱。
當然,一個欄位可以有一個以上的限制條件。只要一個接著一個即可:
撰寫的次序沒有關係,也不需要去計較限制被檢查的次序。
NOT NULL 有一個相反的語法:NULL。這並非表示欄位裡只能是空值,如果這樣的話就完全沒用處了。其實這是一種簡化,將預設值設定為空值。NULL 語法並不是 SQL 標準的一部份,所以請不要用在可移植式的應用程式裡。(這僅是 PostgreSQL 為了相容其他資料庫而增加的功能)然而,有一些使用者喜歡使用它,因為在程序檔的撰寫上,很容易利用這個語法來切換限制條件。舉個例子,你可以先寫下:
然後在需要的時候再適時加入 NOT 關鍵字即可。
在多數資料庫設計原則上,主要欄位都應該被標示為 NOT NULL。
限制唯一性,確保在某個欄位或某一群欄位的資料,是在該表格中獨一無二的。語法如下:
這是欄位限制的語法。而:
則是表格限制的寫法。
如果想要限制一群欄位的唯一性的話,請使用表格限制的語法,欄位名稱以逗號分隔:
這表示這些欄位所包含的內容組合,在整個表格中是具有唯一性的,但任何一個欄位本身並不一定具備唯一性。
你可以命名唯一性的限制條件,語法如下:
一般來說,唯一性被違反的情況是,所限制的欄位在表格中,有超過一列的資料是相等的。不過,空值並不會被計算在內。這表示說,即使設定了唯一性的限制,在被限制的欄位中,還是有可能會有多個列的資料是空值。這個設計源自 SQL 標準,但聽說有其他的 SQL 資料庫並不是這樣的規則。所以,如果要移植這個語法到其他資料庫的話,要注意這項設計有無差異。
主鍵的意思是,某一個欄位或某一群欄位,在整個表格中,其每一列的組合都是唯一的,且有宣告唯一性的限制條件,並且也包含了非空值的條件(UNIQUE 及 NOT NULL)。所以,下面的兩種語法對資料的意義相同:
主鍵也可以包含多個欄位,語法和宣告唯一限制條件類似:
加入主鍵時,會自動建立一個具唯一性的 B-tree 索引,範圍為 PRIMARY KEY 語法所定義的欄位,並且會強制將這些欄位設定為非空值(NOT NULL)。
一個表格只能有一個主鍵。(你可以使用 UNIQUE 及 NOT NULL 設定多個同樣的限制條件,在功能上幾乎是相同的,但只能有一組條件是由 PRIMARY KEY 所定義。)關連式資料庫的理論指出,每一個表格都必須要有一個主鍵。這個規則在 PostgreSQL 中並不是強制的,但通常建議最好遵循這個理論。
主鍵在用戶端文件式的資料處理上是很有用的。舉個例子,一個圖型化介面讓使用者可以修改資料,那麼可能就需要主鍵來確認每一列的唯一性,而不致於產生混淆。也有一些用途是在資料庫系統的管理上,例如,主鍵會用於外部鍵(Foreign Keys)的處理,使其可以處理表格與表格間的資料對應問題。
外部鍵指的是某個欄位或某一群欄位的內容,必須在另一個表格相對欄位之中,存在相同內容的資料。我們會說這樣的行為是在維護兩個表格之間的關連性。
就使用我們已經使用多次的產品表格吧:
讓我們假設你有一個表格用來儲存這些產品的訂單,我們要確保這些訂單內的產品確實存在。所以我們定義一個外部鍵來關連訂單的表格和產品的表格:
這樣的話,如果 product_no 沒有出現在產品表格的話,就無法建立資料了。
我們會說像這樣的情況是,訂單表格是引用表格(referencing table),而產品表格是參考表格(referenced table)。相對地,欄位也稱為引用欄位(referencing columns)及參考欄位(referenced columns)。
你可以將這個語法簡化為:
因為在參考表格中,不在主鍵欄位組合中的欄位,就是參考欄位。
外部鍵也可以參考一組欄位。一般來說,這樣要寫成表格限制條件形式,如下:
當然,組合外部鍵的欄位數量,彼此之間必須要相等。
你可以給外部鍵一個名稱,使用語法與限制條件相同。
一個表格可以有許多個外部鍵,這用於表格之間多對多的關係。例如你有一些表格記錄了很多產品和訂單,但現在你要讓每一筆訂單也可以訂購多項產品(這在先前的語法並不允許)。你也許可以試試這個表格宣告:
注意到這裡的主鍵和外部鍵是重覆的。
我們知道外部鍵不允許沒有關連到產品的訂單,但如果企圖移除一個有訂單的產品會如何呢?SQL 有幾個選項讓你直覺進行這項操作:
不允許移除被參考到的產品
同時也刪去訂單
其他?
要描繪這些情況,讓我們建立如上需求的多對多關連的結構:當某人要移除一個有訂單的產品(以 order_items 關連)時,我們不允許執行。而如果某人移除了一筆訂單,訂單內的項目也會同步被移除:
引用和同步刪除有兩個常見的作法。用「RESTRICT」防止參考的資料被刪除;「NO ACTION」表示當限制條件被違反時,引用欄位的資料仍會留存,然後回傳錯誤訊息,如果未指定處理方式的話,這會是預設的行為(這兩個語法根本上的不同是「NO ACTION」允許延遲檢查到交易事務的最後,而「RESTRICT」則不會。);「CASCADE」指的是當參考的資料列被刪除時,引用的資料列也會同步被刪除。刪除時還有兩個其他的選項:SET NULL 和 SET DEFAULT,表示引用的資料會被更新為空值或其預設值。注意到,這並不是說你就可以違反限制條件。舉個例來說,如果使用了 SET DEFAULT,但預設值卻違反了外部鍵的限制,這個操作將會失敗。
類似的於 ON DELETE 的情況是 ON UPDATE,也就是在參考欄位的資料內容被更新時的情況。可以設定的動作關鍵字是相同的。在這個情況的 CASCADE 指的就是更新參考欄位的資料內容時,引用欄位的內容也會同步被更新為相同的內容。
一般來說,引用的資料列不需要滿足外部鍵的定義,如果其任一欄位內容為空值的話。而如果「MATCH FULL」加到宣告的語法之中的話,引用的資料列就必須要全部都是空值才不受外部鍵的限制(也就是部份空值的資料列就不受限制)。如果要避免空值使得外部鍵失效的話,就應該宣告相關欄位為 NOT NULL。
外部鍵所參考的欄位必須要是主鍵或是宣告其唯一性限制,這表示參考欄位會有索引存在,這使得檢查關連的過程會是很有效率的。因為在刪除或更新參考資料表時,需要檢查引用資料表的情況,所以在引用表格的欄位建立索引,也是常見的作法。因為這並不是一定需要,而還有許多的選擇在於如何索引,所以宣告外部鍵時並不會自行以引用欄位組合建立索引。
除外宣告要確保的是,如果任意兩個資料列在指定的欄位或表示式被比較時,用於特定的運算子,至少有一個比較會回傳假(false)或空值(null)。語法如下:
加入除外宣告時,將會自動建立相對應的索引。
將已經在資料庫中的資料做修改被稱為更新。您可以單獨更新某個資料列,或資料表中的所有資料列,或是部份資料列。每個欄位可以單獨更新,而不影響其他欄位。
要更新現有的資料列,請使用 指令。這需要三種資訊:
要更新的資料表和欄位的名稱
資料欄位新的內容
哪些資料列要更新
回想一下,SQL 通常不提供資料列的唯一識別資訊。因此,直接指定要更新哪一行通常是不行的,而是指定該資料列必須符合哪些條件才能更新。只有你在資料表中有一個主鍵(決定於是否你有宣告過)之後,才能通過選擇與主鍵相匹配的條件來可靠地解決單個資料列的問題。圖形化的資料庫管理工具依賴這個方式才能允許你單獨更新指定的資料列。
例如,這個指令會將價格為 5 的所有產品更新為 10:
這結果可能是零個,一個或多個資料列被更新。嘗試更新卻沒有匹配到任何資料列,並不是一種錯誤。
我們來詳細看看這個命令。首先是關鍵字 UPDATE,然後是資料表的名稱。像往常一樣,資料表的名稱可以使用加上 schema 的完整路徑名稱,否則就會在搜尋路徑中尋找。接下來的關鍵字是 SET,後面接著欄位名稱,等號和新的欄位內容。新的欄位內容可以是任何的運算表示式,而不僅僅是一個常數。例如,如果要將所有產品的價格提高10%,則可以使用:
如你所見,欄位的表示式可以引用資料列中現有的內容。我們還遺漏了 WHERE 子句。如果省略的話,則意味著資料表中的所有資料列都會被更新。如果存在的話,則只有更新符合 WHERE 條件的那些資料列。請注意,SET 子句中的等號是一個賦值運算,而 WHERE 子句中的等號是比較運算,但這不會造成任何誤解。當然,WHERE 條件不一定是等號運算。 還有許多其他的運算子可以使用(詳見第 9 章)。但是表示式需要能產生為布林運算的結果。
您可以在使用 UPDATE 指令時,以 SET 子句中列出多個欄位賦值來更新多個欄位內容。例如:
加入唯一性的限制條件,將會自動建立一個具唯一性的 B-tree 索引,其包含的欄位就如限制條件中所條列的欄位。這樣唯一性限制的語法並不能只限制某部份列的唯一性,但如果使用「 」的話就可以做到。
關於更新資料與刪除資料的細節在。也可以在 語法說明中,找到更多外部鍵的說明。
詳情請參考 中,CONSTRAINT 到 EXCLUDE 的段落。
兩個查詢的結果可以使用集合操作聯、交集和差集來組合。其語法為:
query1 和 query2 是到目前為止討論過的任何查詢功能。集合操作也可以巢狀也可以連接,例如:
會如下方式執行:
UNION 將 query2 的結果有效率地附加到 query1 的結果中(但不能保證這是實際回傳資料列的次序)。此外,除非使用了UNION ALL,否則它將以與 DISTINCT相同的方式從結果中消除重複的資料列。
INTERSECT 返回 query1 的結果和 query2 的結果中所有共同的資料列。除非使用 INTERSECT ALL,否則會刪除重複的資料列。
EXCEPT 回傳 query1 的結果中但不包含在 query2 的結果中的所有資料列。(這有時被稱為兩個查詢之間的差集。)同樣地,除非使用 EXCEPT ALL,否則重複資料列將被刪除。
為了計算兩個查詢的聯集、交集或差集,兩個查詢必須是「union compatible」,這意味著它們回傳相同數量的欄位,相應的欄位具有相容的資料型別,如 10.5 節所述。
LIMIT 和 OFFSET 允許你只回傳由查詢生成的一部分資料列:
如果給了一個限制的數量,那麼只有那個數目的資料列會回傳(如果查詢本身產生較少的資料列,則可能會少一些)。LIMIT ALL 與省略 LIMIT 子句相同,也如同 LIMIT 的參數為 NULL。
OFFSET 指的是在開始回傳資料列之前跳過那麼多少資料列。OFFSET 0 與忽略 OFFSET 子句相同,就像使用 NULL 參數的 OFFSET 一樣。
如果同時出現 OFFSET 和 LIMIT,則在開始計算回傳的LIMIT 資料列之前,先跳過 OFFSET 數量的資料列。
使用 LIMIT 時,運用 ORDER BY 子句將結果資料列限制為唯一順序非常重要。否則,你會得到一個不可預知的查詢資料列的子集。你可能會查詢第十到第二十個資料列,但是第十到第二十個資料列是按什麼順序排列的?次序是未知的,除非你指定 ORDER BY。
查詢最佳化在產生查詢計劃時會將 LIMIT 考慮在內,所以根據你給的 LIMIT 和 OFFSET,你很可能會得到不同的計劃(產生不同的資料列順序)。因此,使用不同的 LIMIT / OFFSET 值來選擇查詢結果的不同子集將導致不一致的結果,除非使用 ORDER BY 強制執行可預測的結果排序。這不是一個錯誤;這是一種事實上的結果,即 SQL 不保證以任何特定順序傳遞查詢的結果,除非使用 ORDER BY 來約束順序。
由 OFFSET 子句跳過的資料列仍然需要在伺服器內計算。因此一個大的 OFFSET 可能是低效率的。
如前一節所述,SELECT 指令中的資料示表表示式透過各種可能地組合資料表、view、消除資料列、分組等來建構中介的虛擬資料表。這個資料表最終會被傳遞給資料列表的處理。資料列表確認中介資料表的哪些欄位是實際上要輸出的。
最簡單的選擇列表是*,它表示資料表表示式產生的所有欄位。否則,資料列表是逗號分隔的參數表示式列表(如第 4.2 節中所定義的)。例如,它可能是欄位名稱的列表:
欄位名稱 a、b 和 c 是 FROM 子句中資料表的欄位的實際名稱,或者是由第 7.2.1.2 節中所賦予它們的別名。資料列表中可用的命名空間與 WHERE 子句中的命名空間相同,除非是使用分組查詢,在這種情況下,它與 HAVING 子句中的相同。
如果多個資料表具有相同名稱的欄位,則還必須加上資料表的名稱,如下所示:
處理多個資料表時,查詢特定資料表的所有欄位也是可以的:
有關 table_name.* 表示法的更多信息,請參閱第 8.16.5 節。
如果在資料列表中使用任意值表示式,則概念上是它將新的虛擬欄位加到回傳的資料表中。參數表示式對每個結果資料列計算一次,將該資料列的值替換為任何欄位引用。但是資料列表中的表示式不必引用 FROM 子句的資料表表示式中的任何欄位;例如,它們可以是常數算術表示式。
資料列表中的項目可以被分配用於後續處理的名稱,例如在 ORDER BY 子句中使用或由用戶端應用程序顯示。 例如:
如果沒有使用 AS 指定輸出欄位的名稱,系統將分配一個預設的欄位名稱。對於簡單欄位的引用,就是引用欄位的名稱。對於函數呼叫,就是函數的名稱。對於複雜的表示式,系統將會產成一個通用的名稱。
AS 關鍵字是選用的,但前提是新的欄位名稱不為任何PostgreSQL 關鍵字(請參閱附錄C)。為避免與關鍵字意外撞名,你可以對欄位名稱使用雙引號。例如,VALUE 是一個關鍵字,所以就不能這樣使用:
但這樣就可以了:
為了防止未來可能增加的關鍵字,建議你習慣使用 AS 或總是在欄位名稱使用雙引號。
注意這裡輸出欄位的命名與 FROM 子句中的命名不同(參閱第 7.2.1.2 節)。可以重新命名相同的欄位兩次,但在資料列表中分配的名稱是將要回傳的名稱。
DISTINCT
在處理了資料列表之後,結果資料表可以選擇性地消除重複的資料列。 DISTINCT 關鍵字在 SELECT 之後直接寫入以指定這個動作:
(如果不是 DISTINCT,而是關鍵字 ALL,可用於指定保留所有資料列的預設行為。)
顯然,如果至少有一個欄位值不同,則兩個資料列就會被認為是不同的。 在這個比較中,空值(null)被認為是相等的。
或者,使用表示式可以指定資料列如何被認為是不同的:
這裡表示式是一個任意的運算表示式,對所有資料列進行求值運算。所有表示式相等的一組資料列被認為是重複的,並且只有該組的第一個資料列會被保留在輸出中。請注意,集合中的「第一行」是不可預知的,除非查詢按足夠的欄位進行排序,以保證進到 DISTINCT 過濾器的資料列是唯一排序。(在 ORDER BY 排序後才進行 DISTINCT ON 處理。)
DISTINCT ON 子句不是SQL標準的一部分,有時被認為是不好的樣式,因為其結果有潛在的不確定性。透過在 FROM 中智慧地使用 GROUP BY 和子查詢,可以避免這種結構,但這卻往往是最方便的選擇。
PostgreSQL 內建一套豐富的資料型別供用戶使用。使用者也可以使用 CREATE TYPE 指令讓 PostgreSQL 增加新的資料型別。
Table 8.1 列出所有內建的通用資料型別。大多數列在「Aliases」中的替代名稱是由於在 PostgreSQL 內部使用的歷史因素。此外,還有一些內部使用或不建議使用的資料型別,但這裡並沒有列出。
Table 8.1. Data Types
Name
Aliases
Description
bigint
int8
signed eight-byte integer
bigserial
serial8
autoincrementing eight-byte integer
bit [ (n
) ]
fixed-length bit string
bit varying [ (n
) ]
varbit
variable-length bit string
boolean
bool
logical Boolean (true/false)
box
rectangular box on a plane
bytea
binary data (“byte array”)
character [ (n
) ]
char [ (n
) ]
fixed-length character string
character varying [ (n
) ]
varchar [ (n
) ]
variable-length character string
cidr
IPv4 or IPv6 network address
circle
circle on a plane
date
calendar date (year, month, day)
double precision
float8
double precision floating-point number (8 bytes)
inet
IPv4 or IPv6 host address
integer
int
,int4
signed four-byte integer
interval [fields
] [ (p
) ]
time span
json
textual JSON data
jsonb
binary JSON data, decomposed
line
infinite line on a plane
lseg
line segment on a plane
macaddr
MAC (Media Access Control) address
macaddr8
MAC (Media Access Control) address (EUI-64 format)
money
currency amount
numeric [ (p
,s
) ]
decimal [ (p
,s
) ]
exact numeric of selectable precision
path
geometric path on a plane
pg_lsn
PostgreSQLLog Sequence Number
point
geometric point on a plane
polygon
closed geometric path on a plane
real
float4
single precision floating-point number (4 bytes)
smallint
int2
signed two-byte integer
smallserial
serial2
autoincrementing two-byte integer
serial
serial4
autoincrementing four-byte integer
text
variable-length character string
time [ (p
) ] [ without time zone ]
time of day (no time zone)
time [ (p
) ] with time zone
timetz
time of day, including time zone
timestamp [ (p
) ] [ without time zone ]
date and time (no time zone)
timestamp [ (p
) ] with time zone
timestamptz
date and time, including time zone
tsquery
text search query
tsvector
text search document
txid_snapshot
user-level transaction ID snapshot
uuid
universally unique identifier
xml
XML data
以下資料型別(或其拼寫方式)是由 SQL 指定的:bigint
,bit
,bit varying
,boolean
,char
,character varying
,character
,varchar
,date
,double precision
,integer
,interval
,numeric
,decimal
,real
,smallint
,time
(with or without time zone),timestamp
(with or without time zone),xml
.
每種資料型別都具有其明確的輸入和輸出功能外部表示法。許多內建的資料型別都有明顯的外部格式。但是,有幾種資料型別是 PostgreSQL 獨有的,比如幾何路徑,或者有幾種可能的格式,像是日期和時間型別。某些輸入和輸出功能是不可逆的,意即,與原始輸入相比,輸出功能的結果可能會失去一些精確度。
WITH 提供了一種撰寫用於更複雜查詢輔助語句的方法。這些通常被稱為公用資料表表示式或 CTE(Common Table Expressions) 的宣告可以被想成是定義僅存在於一個查詢中的臨時資料表。WITH子句中的每個輔助語句都可以是 SELECT、INSERT、UPDATE 或 DELETE;並且 WITH 子句本身附加到 SELECT、INSERT、UPDATE 或 DELETE 的主語句。
SELECT
inWITH
SELECT 中 WITH 的基本價值是將複雜的查詢分解為較為簡單的部分。一個例子是:
其中僅顯示最上層銷售區域中的每個產品的銷售總計。WITH 子句定義了兩個名為 regional_sales 和 top_regions 的輔助語句,其中 top_size 使用 region_sales 的輸出,top_regions 的輸出在主 SELECT 語句中使用。這個例子本來可以不用 WITH 編寫,但是我們需要兩層的SELECT 子查詢。按照這種方式更容易一些。
選擇性的 RECURSIVE 修飾字將 WITH 從單純的語法便利性增加了標準 SQL 所無法實現的功能。使用 RECURSIVE,WITH 查詢可以引用它自己的輸出。一個非常簡單的例子是這個查詢來從 1 到 100 的整數求和:
遞迴 WITH 查詢的一般形式始終是非遞迴子句,然後是 UNION(或 UNION ALL),然後是遞迴子句,其中只有遞迴子句可以包含對查詢自己的輸出引用。這樣的查詢執行如下:
執行遞迴查詢
執行非遞迴子句。 對於 UNION(但不是 UNION ALL),丟棄重複的資料列。在遞迴查詢的結果中包含所有剩餘的資料列,並將它們放在臨時的工作資料表中。
只要工作資料表不是空的,就重複這些步驟:
執行遞迴子句,將工作資料表的當下的內容替換為遞迴自我引用。對於 UNION(但不是 UNION ALL),將重複的資料列及和之前結果重覆的資料列都丟棄。在遞迴查詢的結果中包含所有剩餘的資料列,並將其放置在臨時中介資料表中。
將工作資料表的內容替換為中介資料表的內容,然後清空中介資料表。
注意嚴格地說,這個過程仍然是疊代的而不是遞迴的,但是 RECURSIVE 是 SQL 標準委員會所選擇的用字。
在上面的例子中,工作資料表在每一步驟中只有一個資料列,並且在連續的步驟中從 1 取值到 100。在第 100 步時,由於 WHERE 子句而沒有輸出,因此結束查詢。
遞迴查詢通常用於處理分層或樹狀結構的資料。一個實用的例子是,這個查詢用來找到產品的所有直接和間接子部分,只產出一個顯示即時包含這些資訊的資料表:
使用遞迴查詢時,務必確保查詢的遞迴部分最終不回傳資料列,否則查詢將會無限循環。有時,使用 UNION 而不是 UNION ALL 可以透過丟棄與先前輸出行重覆的資料列來達成此目的。但是,循環查詢通常不涉及完全重複的輸出資料列:可能需要檢查一個或幾個欄位,以查看是否在之前就已經達到相同的點。處理這種情況的標準方法是從已經訪問過的陣列中,計算其值。例如,以下查詢是,使用連接欄位搜尋資料表網路圖:
如果連接關係包含循環,則此查詢將持續循環。因為我們需要一個「depth」輸出,只要將 UNION ALL 更改為 UNION 就不會停止循環。相反地,我們需要瞭解到,在遵循特定的連接路徑的情況下,我們是否再一次到達同樣的資料列。我們增加兩個欄位 path 和 cycle 到有循環傾向的查詢之中:
除了防止循環之外,陣列內容本身通常也是有用的,表示為達到任何特定資料列所採取的「path」。
在一般情況下,需要檢查多個欄位來識別是一個循環,請使用資料列陣列來處理。例如,如果我們需要比較欄位 f1 和 f2:
小技巧在通常情況下,只需要檢查一個欄位來識別週期,就會省略 ROW() 語法。這可以使用簡單的陣列而不用複合型別的陣列,從而獲得效率。
小技巧遞迴查詢評估演算法以廣度優先搜尋次序產生其輸出。你也可以按照深度優先的搜尋順序顯示結果,方法是以外部查詢 ORDER BY 「path」欄位。
當你不確定是否可能會形成循環時,測試查詢的一個有用的技巧是在父查詢中放置一個 LIMIT。例如,這個查詢沒有 LIMIT,將會無限循環:
這是有效的,因為 PostgreSQL 的實作的關係,看起來像是執行一個 WITH 查詢的許多行,但實際上是由父查詢獲取的。不建議在產品階段中使用這個技巧,因為其他系統的工作方式可能不同。此外,如果你以外部查詢對遞迴查詢的結果進行排序或將它們與某個其他資料表交叉查詢,則通常不可行,因為在這種情況下,外部的查詢通常會嘗試獲取所有 WITH 查詢的輸出。
WITH 查詢的一個有用的屬性是,每次執行父查詢時,它們只被評估一次,即使它們被父查詢或兄弟的 WITH 查詢引用多次。因此,在多個地方需要昂貴的計算可以放在 WITH 查詢中以避免重複的工作。另一個可能的應用是防止不必要多重評估的副作用。然而,如同硬幣有反面一樣,查詢優化器不太可能限制從父查詢向下推入的是 WITH 查詢而不是普通的子查詢。WITH 查詢通常會按其撰寫方式進行評估,而不會抑制父查詢之後可能丟棄的資料列。(但是,如上所述,如果查詢的引用只需要有限的資料列數量,評估可能會提前結束。)
上面的例子只說明 WITH 與 SELECT 一起使用,但是它也可以以同樣的方式附加到INSERT、UPDATE 或 DELETE。在每種情況下,它都有效地提供了可以在主查詢中可引用的臨時資料表。
你可以在 WITH 中使用資料修改語法(INSERT、UPDATE 或 DELETE)。 這使你可以在同一個查詢中執行多個不同的操作。範例如下:
這個查詢有效地將資料列從 products 搬移到products_log。WITH 中的 DELETE 從 products 中刪除指定的資料列,透過 RETURNING 子句回傳其內容;然後主查詢讀取該輸出並將其插入到 products_log 中。
上面例子的很好的一點是,WITH 子句被附加到 INSERT,而不是使用 INSERT 中的子查詢。這是必要的,因為資料修改語句只能在最上層語句的 WITH 子句中使用。但是,以一般的 WITH 變數可見性規則,可以從子查詢中引用 WITH 語句的輸出。
WITH 中的資料修改語句通常具有 RETURNING 子句(詳見第 6.4 節),如上例所示。它是 RETURNING 子句的輸出,而不是資料修改語句的目標資料表,它構成了查詢的其餘部分可以引用的臨時資料表。如果 WITH 中的資料修改語句沒有 RETURNING 子句,則它就不構成臨時資料表,並且不能在查詢的其餘部分引用。這樣的陳述將被執行。一個不是特別有用的例子是:
這個例子將刪除 foo 和 bar 資料表中的所有資料列。報告給客戶端的受影響資料列的數量將只包括從 bar 中刪除的資料列。
資料修改語句中的遞迴的自我引用是不被允許的。在某些情況下,可以通過引用遞迴 WITH 的輸出來解決這個限制,例如:
該查詢將刪除產品的所有直接和間接子部分。
WITH 中的資料修改語句只執行一次,並且一定會完成,與主查詢是否讀取其所有(或者甚至是任何)輸出無關。請注意,這與 SELECT 在 WITH 之中的規則不同:如前一節所述,僅在主要查詢要求其輸出的情況下執行 SELECT。
WITH 中的子語句會與主查詢平行執行。因此,在 WITH 中使用資料修改語句時,指定更新的實際發生順序是不可預知的。所有的語句都使用相同的快照執行(見第 13 章),所以它們不能在目標資料表上「看到」對方所產生的變更。 這減輕了資料列更新的實際順序時不可預測性的影響,並且意味著回傳資料是在不同 WITH 子語句和主查詢之間傳遞變化的唯一方式。 範例如下所示:
外面的 SELECT 將會在 UPDATE 的執行之前就回傳原始價格
外面的 SELECT 將會回傳更新後的資料。
企圖在單個語句中更新同一資料列兩次是不被允許的。只有一個修改會發生,但是要可靠地預測哪一個是不容易的(有時不可能)。 這也適用於刪除已在同一語句中更新的資料列:僅更新會被執行。因此,通常你應該避免企圖在單個語句中修改單個資料列兩次。特別注意避免在 WITH 子語句中使用可能會被主語句或其子查詢所影響的資料列。這種查詢語句的效果是不可預測的。
目前來說,在 WITH 中使用資料修改語句的目標資料表都不能有條件規則,也不能有 ALSO 規則,也不能有擴展為多個語句的 INSTEAD 規則。
在查詢產生了一個輸出資料表(處理了資料列表之後)之後,可以對其資料列進行排序。如果未選擇排序,則資料列將以未指定的順序回傳。在這種情況下的實際順序將取決於資料掃描和交叉查詢類型以及磁碟上的順序,但不能依賴它。只有明確選擇了排序方式,才能保證特定的輸出排序。
以 ORDER BY 子句指定排序順序:
排序表示式可以在查詢的資料列表中有效的任何表示式。 一個例子是:
當指定多個表示式時,後面的表示式用於前面表示式都相同的資料進行排序。每個表示式可以跟隨一個選擇性的 ASC 或 DESC 關鍵字來設定排序方向為升冪或降冪。 ASC 排序是預設的選項。升冪首先放置較小的值,其中「較小」是根據「<」運算元定義的。 同樣,降冪也是由「>」運算元決定的。
NULLS FIRST 和 NULLS LAST 選項可用於確定在排序順序中是否出現空值出現在非空值之前或之後。預設情況下,空值排序大於任何非空值;也就是 NULLS FIRST 是 DESC 選項的預設值,否則就是 NULLS LAST。
請注意,排序選項是針對每個排序欄位獨立考慮的。例如 ORDER BY x, y DESC 是指 ORDER BY x ASC, y DESC,它與 ORDER BY x DESC, y DESC 不同。
排序表示式也可以是輸出欄位的欄位標籤或編號,如下所示:
兩者都按第一個輸出欄位排序。請注意,輸出欄位名稱必須獨立,也就是說,不能在表示式中使用 - 例如,這樣是不正確的:
這種限制是為了減少歧義。 即使 ORDER BY 項目是一個簡單的名字,可以匹配輸出欄位名稱或者資料表表示式中的一項,這仍然是會混淆的。在這種情況下請使用輸出欄位。如果您使用 AS 來重新命名輸出欄位以匹配其他資料表欄位的名稱,只會導致混淆。
可以將 ORDER BY 應用於 UNION、INTERSECT 或 EXCEPT 組合的結果,但在這種情況下,只允許按輸出欄位名稱或數字進行排序,而不能使用表示式進行排序。
貨幣型別儲存具有固定小數精確度的貨幣數量;詳見表 8.3。 小數精確度視資料庫的 設定而定。表中顯示的範圍假設有兩個小數位。有許多可以接受的格式,包括整數和浮點數字,以及典型的貨幣格式,例如如「$1,000.00」。 輸出時通常採用後者的形式,但取決於語言環境(locale)。
Table 8.3. Monetary Types
由於此資料型別的輸出是與區域設定有關的,因此可能無法將貨幣資料載入到不同 lc_monetary 設定的資料庫中。為避免出現問題,在將轉換恢復到新的資料庫之前,請確保 lc_monetary 與轉換的資料庫中的設定值相容。
numberic、int 和 bigint 資料型別的值可以轉換為 money。從 real 和 double precision 資料型別轉換會先轉為 numeric 來完成,例如:
但是,並不推薦這樣做。由於四捨五入誤差的可能性,不應該使用浮點數來處理貨幣。
money 型別的數值可以轉換為 numeric 而不會損失精確度。轉換為其他型別可能會失去精確性,而且還必須分兩步驟完成:
當貨幣數值除以另一貨幣數值時,結果會是 double precision(即純數,而不是貨幣);貨幣單位會相互抵消。
VALUES 提供了一種產生「靜態資料表」的方法,可以在查詢中使用,而不必實際創建和寫入磁碟上的資料表。其語法是
每個括號內的表示式列表在資料表中生成一個資料列。列表必須具有相同數量的元素(即資料表中的欄位數),並且每個列表中的對應條目必須具有兼容的資料型別。 分配給結果中每個欄位的實際資料型別,使用與 UNION 相同的規則來給定(請參閱)。
如下範例所示:
將回傳一個兩個欄位三個資料列的資料表。這實際上相當於:
預設情況下,PostgreSQL 會將名稱 column1、column2 等分配給 VALUES 資料表的欄位。欄位名稱並不是由 SQL 標準規定的,不同的資料庫系統會以不同的方式賦予,所以通常以資料表別名列表覆寫預設名稱會比較好,如下所示:
在語法上,VALUES 接在表示式列表之後被視為等同於:
並可以出現在任何一個 SELECT 可以使用的地方。例如,你可以將其用作為 UNION 的一部分,或者為其增加排序規則(ORDER BY、LIMIT 和 OFFSET)。在 INSERT 命令中,VALUES 最常來作為資料源,其次最常在子查詢。
bytea 資料型別允許儲存位元組字串;詳見 。
位元組字串是位元組的序列。位元組字串以兩種方式與字串區分開來。首先,位元組字串特別允許儲存零值的位元組和其他「不可列印」位元組(通常是在 32 到 126 範圍之外的位元組)。字串不允許全為零位元組,並且還禁止資料庫選擇無效的字元集編碼序列。其次,對位元組字串的操作處理實際的位元組,而字串的處理取決於區域設定。簡而言之,位元組字串適合於儲存程式設計師認為是「raw bytes」的資料,而字串適合於儲存文字。
bytea 型別支援兩種輸入和輸出的外部格式:PostgreSQL 既有的「escape」格式和「十六進位」格式,輸入時始終接受這兩個。輸出格式取決於組態參數 ;預設值為十六進位。(注意,在 PostgreSQL 9.0 中引入了十六進位格式;早期版本和一些工具並無法解譯它。)
SQL 標準定義了一種不同的位元組字串型別,稱為 BLOB 或 BINARY LARGE OBJECT。輸入格式與 bytea 不同,但提供的函數和運算子大致相同。
bytea
十六進位格式「十六進位」格式將二進位資料編碼為每個位元組為 2 個十六進位數字,儲存不反轉。整個字符串前面是序列 \x(以區別於轉譯格式)。在某些情況下,初始倒斜線可能需要透過加倍來進行轉譯,在相同的情況下,倒斜線必須以轉譯格式加倍;細節如下。十六進位數字可以是大寫或小寫,並且在數字組之間允許空格(但不在數字組內,也不在起始 \x 序列中)。十六進位格式與各種外部應用程序和協議相容,並且轉換速度往往比轉譯格式更快,因此偏好使用它。
例如:
bytea
轉譯(escape)格式「轉義」格式是 bytea 型別的傳統 PostgreSQL 格式。它採用將位元組字串表示為 ASCII 字元序列的方法,同時將那些不能表示為 ASCII 字元的位元組轉換為特殊的轉譯序列。如果從應用程序的角度來看,將位元組表示為字元是有意義的,那麼這種表示可以很方便。但實際上它通常會令人困惑,因為它模糊了位元組字串和字串之間的區別,而且所選擇的特定轉譯機制也有點笨拙。因此,對於大多數新的應用程序,應該避免使用此格式。
以轉譯格式輸入 bytea 值時,必須轉譯某些值的位元組,也同時可以轉譯所有位元組值。通常,要轉譯位元組,請將其轉換為三位數的八進位值,並在其前面加一個倒斜線(或兩個倒斜線,如果要使用轉譯字串語法將值寫為文字的話)。倒斜線本身(位元組 92)也可以用雙倒斜線表示。 列出了必須轉譯的字元,並在適合的情況下提供了備用轉譯序列。
bytea
Literal Escaped Octetsbytea
Output Escaped Octets根據您使用的 PostgreSQL 的前端,在轉譯和未轉譯 bytea 字串方面可能還有其他工作要做。例如,如果您的界面會自動轉譯這些,您可能還必須轉譯換行符號和回行首符號。
數字型別由兩位數,四位數和八位數整數,四位元組和八位元組的浮點數以及可調式精確度的小數組成。列出了可用的類型。
描述了數字型別常數的語法。 數字型別有一整套相應的算術運算元和函數。有關更多訊息,請參閱第 9 章。 以下各節將詳細介紹這些型別。
smallint、integer 和 bigint 型別儲存整數,即不包含小數部分的各種範圍的數字。嘗試儲存在允許的範圍之外的數值將會導致錯誤。
「integer」型別是常見的選擇,因為它提供了數值範圍、儲存空間及效能之間的最佳平衡。「smallint」 列別通常只在磁碟空間不足的情況下使用。「bigint」 型別被設計用於整數型別的範圍不足時。
SQL僅指定整數型別 integer(或 int)、smallint 和 bigint。 型別名稱 int2、int4 和 int8 則是延伸型別,也有一些其他 SQL 資料庫系統使用。
數字型別可以儲存很多位數的數字。特別建議使用在要求正確性的地方,像是儲存貨幣金額或其他數量。使用數值的計算在可能需要的情況下得到確切的結果,例如 加法、減法、乘法。但是,與整數型別或下一節中介紹的浮點型別相比,對數值的計算速度非常緩慢。
我們使用下面的術語:數字的「scale」是小數點右邊的小數部分,也就是小數的位數。數字的「precision」是整數中有效位數的總數,即小數點兩邊的位數總合。所以 23.5141 的 precision 是 6,scale 是 4。整數可以被認為是 scale 為 0。
可以配置數字欄位的最大 precision 和最大 scale。要宣告數字型別的欄位,請使用以下語法:
precision 必須是正值,scale 為零或正值。或是:
選擇 0 為 scale。這樣使用:
沒有任何 precision 或 scale 的話,就會建立一個欄位,其欄位中可以儲存任何 precision 和 scale 的數字值,直到達到 precision 的極限。這種型別的欄位不會將輸入值強制轉為任何特定的 scale,其中具有聲明比例的數字欄位會將輸入值強制為該 scale。 (SQL 標準需要預設 scale 為 0,即強制為整數精度,我們發現這樣做有點無用。如果你擔心可移植性,請務必明確指定 precision 和 scale。
注意在型別宣告中明確指定時允許的最大 precision 為 1000;沒有指定 precision 的NUMERIC 為 Table 8.2 中所述的限制。
如果要儲存的小數位數大於欄位所宣告的 scale,則係統會將值四捨五入到宣告所指定的小數位數。然後,如果小數點左邊的位數超過宣告的 precise 減去聲明的 scale 的話,則會產生錯誤。
數字內容的實體儲存不會有任何額外的前導位數或補零。因此,欄位宣告的 precise 和 scale 是最大值,而不是固定的分配。(在這個意義上,數字型別更像是 varchar(n) 而不是 char(n)。) 實際儲存的要求是每四個十進制數字組加兩個位元組,再加上三到八個位元組的額外配置。
除了普通的數值之外,數字型別還允許特殊值 NaN,意思是「不是一個數字」。 NaN 的任何操作都會產生另一個 NaN。在 SQL 指令中將此值作為常數寫入時,必須在其中使用單引號,例如 UPDATE table SET x = 'NaN'。 在輸入時,字串 NaN 識別是不區分大小寫的。
注意「非數字」的概念在大多數實作中,NaN 不被視為等於任何其他數值(包括 NaN)。為了允許數值在樹狀索引中排序和使用,PostgreSQL 將 NaN 值視為相等或大於所有的非 NaN 值。
decimal 和 numeric 的型別是相同的。 這兩種型別都是 SQL 標準的一部分。
當需要四捨五入時,數字型別會往離零較遠的值調整,而(在大多數機器上)實數和雙精度型別會調整到最接近的偶數。 例如:
資料型別中 real 和 double 是非精確的、可變精確度的數字型別。在實務上,這些型別通常是針對二進制浮點數運算(分別為單精度和雙精度)的IEEE 754標準的實作,需要底層的中央處理器、作業系統和編譯器支持。
非精確意味著某些值不能完全轉換為內部格式,並以近似值儲存,因此儲存和檢索值可能會表現出輕微的差異。管理這些誤差以及它們如何計算傳遞是數學和計算機科學分支的主題,除了以下幾點之外,這裡不再討論:
如果你需要精確的儲存和計算(例如貨幣金額),請改為使用 numeric 型別。
如果你想對這些型別做任何重要的複雜計算,特別是如果你依賴邊界情況下的某些行為(極大極小值或超過上下限),你應該仔細評估實作方式。
比較兩個相等的浮點數值可能並不總是按預期中直覺的方式運作。
在大多數平台上,real 型別的範圍至少為 1E-37 至 1E + 37,精確度至少為 6 位數十進制數字。double 型別的範圍通常在 1E-307 至 1E + 308 之間,精確度至少為 15 位數。數值太大或太小都會導致錯誤。如果輸入數字的精確度太高,四捨五入的情況則可能會發生。數字太接近於零,卻不能表示為零的話,將導致 underflow 超過下限的錯誤。
注意
除了普通的數值之外,浮點型別還有幾個特殊的值:
Infinity
-Infinity
NaN
這些分別代表 IEEE 754 特殊值「無限大」、「負無限大」和「非數字」。(在浮點數計算不符合 IEEE 754 標準的機器上,這些值可能無法如期運作。)在 SQL 指令中將這些值作為常數寫入時,必須在其放入單引號中,例如 UPDATE table SET x = '-Infinity'。 在輸入時,這些字串識別是不區分大小寫的。
注意IEEE 754 規定 NaN 不應與任何其他浮點數值(包括NaN)相等。為了允許浮點值在樹狀索引中排序和使用,PostgreSQL 將 NaN 視為相等或大於所有非 NaN 的數值。
PostgreSQL 也支援 SQL 標準的 float 和 float(p) 來表示非精確的數字型別。這裡,p 指的是二進位數字的最小可接受的精確度。PostgreSQL 接受 float(1) 到 float(24) 選擇視為 real 型別,而 float(25) 到 float(53) 則視為 double。p 超出允許範圍的話會產生錯誤。沒有指定精確度的浮點數意味著 double。
注意假設 real 和 double 的尾數分別為 24 位和 53 位,以 IEEE 標準浮點數實作而言是正確的。在非 IEEE 平台上,它可能會有一些小問題,但為了簡單起見,最好在所有平台上都使用相同的 p 範圍。
注意
資料型別 smallserial、serial 和 bigserial 都不是真正的型別,而僅僅是建立唯一識別欄位(類似於某些其他資料庫所支援的 AUTO_INCREMENT 屬性)的方便型別語法。以目前的實作方式,請使用:
相當於以下的指令:
因此,我們建立了一個整數欄位,並將其預設值設定為序列數字產生器。使用 NOT NULL 限制條件來確保無法插入空值。(在大多數情況下,你還需要附加一個 UNIQUE 或 PRIMARY KEY 限制條件來防止偶然插入重複值,但這不是自動的。) 最後,這個序列被標記為「owned by」欄位,以便在欄位或資料表被刪除時一併被刪除。
注意
要將序列的下一個值插入到序列欄位中,請指定序列欄位應被分配其預設值。這可以透過從 INSERT 語句中欄位列表中排除欄位或使用DEFAULT關鍵字來完成。
型別名稱 serial 和 serial4 是等價的:都是建立整數(integer)欄位。型別名稱 bigserial 和 serial8 也以相同的方式作用,差別是他們建立一個 bigint 的欄位。如果你預期在資料表的整個生命週期中使用超過 2^31 個標識符,則應使用 bigserial。型別名稱 smallserial 和 serial2 也是以相同的,而除了它們是建立一個 smallint 欄位。
當擁有的欄位被刪除時,為序列欄位創建的序列也將自動刪除。但你可以刪除序列而不刪除欄位,這會強制刪除欄位的預設表示式。
PostgreSQL 支援完整的 SQL 日期和時間格式,如表 8.9 所示。對於這些資料型態能使用的操作,將會在說明。
Table 8.9. 日期/時間型態
SQL 標準中要求 timestamp
的效果等同於 timestamp without time zone
,對此 PostgreSQL 尊重這個行為。同時 PostgreSQL 額外擴充了 timestamptz
作為 timestamp with time zone
的縮寫。
time
、timestamp
和 interval
接受 p
作為非必須的精度參數,可指定秒的欄位保留的小數位數。預設情況下,精度沒有明確的界限。其中 p
允許的範圍是 0 到 6。
interval
型態有個額外的選項,可以寫下下列其中一個詞組來限制存放的欄位:
需注意若是 fields
和 p
同時指定時,fields
必須要包含 SECOND
。這是因為精度只會套用在秒上。
time with time zone
型態是由 SQL 標準所定義的,但是在定義中展示的屬性會導致對有用性產生疑問。在多數狀況下,date
、time
、timestamp without time zone
和 timestamp with time zone
的組合應該就能提供任何應用程式需要的完整日期/時間功能。
abstime
和 reltime
型態是較低精度的內部用型態,並不建議將這些型態用在應用程式中;這些內部型態也可能在未來的釋出中消失。
其中 p
是非必須的精度設定,用來指定秒欄位的小數位數。精度可以用來指定 time
、timestamp
和 interval
型態,可指定範圍為 0 到 6。如果沒有指定精度時,預設將以字面數值的精度為準(但最多不超過 6 位)。
表 8.10. 日期輸入
time-of-day 格式包含 time [ (p
) ] without time zone和
time [ (_
p_\) \] with time zone
,其中 time
單獨出現時等同於 time without time zone
。
表 8.11. 時間輸入
表 8.12. 時區輸入
時間戳記型態的合法輸入,依序包含了日期、時間、非必須的時區、以及非必須的 AD
或者 BC
。 (其中,AD
或者 BC
也可以寫在時區前面,但這並非推薦的格式。)因此:
以及:
都是遵循 ISO 8601 標準的合法值。除此之外,常見的格式:
也有支援。
SQL 標準中,timestamp without time zone
和 timestamp with time zone
字面可以在時間後面加上 “+” 或 “-” 符號和時差來做區別,因此根據這個標準,
是 timestamp without time zone
型態,而
則是 timestamp with time zone
型態。PostgreSQL 從不會在識別型態前就解析字面的內容,因此會將上述兩種值都視為 timestamp without time zone
型態。如要確保字面會被視為 timestamp with time zone
,請給它正確而明確的型態:
在一個已被確定為沒有時區的時間戳記的字串中,PostgreSQL 將默默地忽略任何時區指示。也就是說,結果值是從輸入值中的日期/時間字串產生的,而不針對時區進行調整。
沒有時區的時間戳記和帶時區的時間戳記之間的轉換通常假定應該採用沒有時區值的時間戳記或本地時間所給予的時區。可以使用 AT TIME ZONE 為指定轉換不同的時區。
為方便起見,PostgreSQL 支援幾個特殊的日期/時間輸入值,如 Table 8.13 所示。infinaity 和 -infinity 值在系統內部有特別的表示,但不會顯示;而其他的只是符號縮寫,在閱讀時會轉換為普通的日期/時間值。(特別是,now 和相關的字串一旦被讀取就會被轉換為特定的時間值。)當在 SQL 命令中要作為常數使用時,所有這些值都需要用單引號括起來。
Table 8.13. Special Date/Time Inputs
Table 8.14. Date/Time Output Styles
ISO 8601 specifies the use of uppercase letter T
to separate the date and time. PostgreSQLaccepts that format on input, but on output it uses a space rather than T
, as shown above. This is for readability and for consistency with RFC 3339 as well as some other database systems.
Table 8.15. Date Order Conventions
Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900s, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules. PostgreSQL uses the widely-used IANA (Olson) time zone database for information about historical time zone rules. For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.
PostgreSQL endeavors to be compatible with the SQL standard definitions for typical usage. However, the SQL standard has an odd mix of date and time types and capabilities. Two obvious problems are:
Although the date
type cannot have an associated time zone, the time
type can. Time zones in the real world have little meaning unless associated with a date as well as a time, since the offset can vary through the year with daylight-saving time boundaries.
The default time zone is specified as a constant numeric offset from UTC. It is therefore impossible to adapt to daylight-saving time when doing date/time arithmetic across DST boundaries.
To address these difficulties, we recommend using date/time types that contain both date and time when using time zones. We do not recommend using the type time with time zone
(though it is supported by PostgreSQL for legacy applications and for compliance with the SQL standard). PostgreSQL assumes your local time zone for any type containing only date or time.
PostgreSQL allows you to specify time zones in three different forms:
In addition to the timezone names and abbreviations, PostgreSQL will accept POSIX-style time zone specifications of the form STDoffset
or STDoffsetDST
, where STD
is a zone abbreviation, offset
is a numeric offset in hours west from UTC, and DST
is an optional daylight-savings zone abbreviation, assumed to stand for one hour ahead of the given offset. For example, if EST5EDT
were not already a recognized zone name, it would be accepted and would be functionally equivalent to United States East Coast time. In this syntax, a zone abbreviation can be a string of letters, or an arbitrary string surrounded by angle brackets (<>
). When a daylight-savings zone abbreviation is present, it is assumed to be used according to the same daylight-savings transition rules used in the IANA time zone database's posixrules
entry. In a standard PostgreSQL installation, posixrules
is the same as US/Eastern
, so that POSIX-style time zone specifications follow USA daylight-savings rules. If needed, you can adjust this behavior by replacing the posixrules
file.
In short, this is the difference between abbreviations and full names: abbreviations represent a specific offset from UTC, whereas many of the full names imply a local daylight-savings time rule, and so have two possible UTC offsets. As an example, 2014-06-04 12:00 America/New_York
represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT
specifies that same time instant. But 2014-06-04 12:00 EST
specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date.
To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK
has meant UTC+3 in some years and UTC+4 in others. PostgreSQLinterprets such abbreviations according to whatever they meant (or had most recently meant) on the specified date; but, as with the EST
example above, this is not necessarily the same as local civil time on that date.
One should be wary that the POSIX-style time zone feature can lead to silently accepting bogus input, since there is no check on the reasonableness of the zone abbreviations. For example, SET TIMEZONE TO FOOBAR0
will work, leaving the system effectively using a rather peculiar abbreviation for UTC. Another issue to keep in mind is that in POSIX time zone names, positive offsets are used for locations west of Greenwich. Everywhere else, PostgreSQLfollows the ISO-8601 convention that positive timezone offsets are east of Greenwich.
In all cases, timezone names and abbreviations are recognized case-insensitively. (This is a change from PostgreSQL versions prior to 8.2, which were case-sensitive in some contexts but not others.)
The SQL command SET TIME ZONE
sets the time zone for the session. This is an alternative spelling of SET TIMEZONE TO
with a more SQL-spec-compatible syntax.
The PGTZ
environment variable is used by libpq clients to send a SET TIME ZONE
command to the server upon connection.
interval
values can be written using the following verbose syntax:
Quantities of days, hours, minutes, and seconds can be specified without explicit unit markings. For example, '1 12:59:10'
is read the same as '1 day 12 hours 59 min 10 sec'
. Also, a combination of years and months can be specified with a dash; for example '200-10'
is read the same as '200 years 10 months'
. (These shorter forms are in fact the only ones allowed by the SQL standard, and are used for output when IntervalStyle
is set to sql_standard
.)
Interval values can also be written as ISO 8601 time intervals, using either the “format with designators” of the standard's section 4.4.3.2 or the “alternative format” of section 4.4.3.3. The format with designators looks like this:
Table 8.16. ISO 8601 Interval Unit Abbreviations
In the alternative format:
the string must begin with P
, and a T
separates the date and time parts of the interval. The values are given as numbers similar to ISO 8601 dates.
When writing an interval constant with a fields
specification, or when assigning a string to an interval column that was defined with a fields
specification, the interpretation of unmarked quantities depends on the fields
. For example INTERVAL '1' YEAR
is read as 1 year, whereas INTERVAL '1'
means 1 second. Also, field values “to the right” of the least significant field allowed by the fields
specification are silently discarded. For example, writing INTERVAL '1 day 2:03:04' HOUR TO MINUTE
results in dropping the seconds field, but not the day field.
According to the SQL standard all fields of an interval value must have the same sign, so a leading negative sign applies to all fields; for example the negative sign in the interval literal '-1 2:03:04'
applies to both the days and hour/minute/second parts. PostgreSQL allows the fields to have different signs, and traditionally treats each field in the textual representation as independently signed, so that the hour/minute/second part is considered positive in this example. If IntervalStyle
is set to sql_standard
then a leading sign is considered to apply to all fields (but only if no additional signs appear). Otherwise the traditional PostgreSQL interpretation is used. To avoid ambiguity, it's recommended to attach an explicit sign to each field if any field is negative.
Internally interval
values are stored as months, days, and seconds. This is done because the number of days in a month varies, and a day can have 23 or 25 hours if a daylight savings time adjustment is involved. The months and days fields are integers while the seconds field can store fractions. Because intervals are usually created from constant strings or timestamp
subtraction, this storage method works well in most cases. Functions justify_days
and justify_hours
are available for adjusting days and hours that overflow their normal ranges.
In the verbose input format, and in some fields of the more compact input formats, field values can have fractional parts; for example '1.5 week'
or '01:02:03.45'
. Such input is converted to the appropriate number of months, days, and seconds for storage. When this would result in a fractional number of months or days, the fraction is added to the lower-order fields using the conversion factors 1 month = 30 days and 1 day = 24 hours. For example,'1.5 month'
becomes 1 month and 15 days. Only seconds will ever be shown as fractional on output.
Table 8.17. Interval Input
The sql_standard
style produces output that conforms to the SQL standard's specification for interval literal strings, if the interval value meets the standard's restrictions (either year-month only or day-time only, with no mixing of positive and negative components). Otherwise the output looks like a standard year-month literal string followed by a day-time literal string, with explicit signs added to disambiguate mixed-sign intervals.
The output of the postgres_verbose
style matches the output of PostgreSQL releases prior to 8.4 when the DateStyle
parameter was set to non-ISO
output.
The output of the iso_8601
style matches the “format with designators” described in section 4.4.3.2 of the ISO 8601 standard.
Table 8.18. Interval Output Style Examples
Table 8.4. Character Types
Table 8.4 列出了 PostgreSQL 中可用的通用字串型別。
SQL 定義了兩種主要字串型別:character varying(n) 和 character(n),其中 n 是正整數。這兩種型別都可以儲存長度最多為 n 個字元(不是位元組)的字串。嘗試將較長的字串儲存到這些型別的欄位中將産生錯誤,除非多餘的字元都是空格,在這種情況下,字串將被截斷為最大長度。(這個有點奇怪的異常是 SQL 標準所要求的。)如果要儲存的字串比宣告的長度短,則 character 型別的值將被空格填充;character varying 的值將只儲存較短的字串。
如果明確地將值轉換為 character varying(n) 或 character(n),則超長值將被截斷為 n 個字元而不會引發錯誤。(這也是 SQL 標準所要求的。)
型別 varchar(n) 和 char(n) 分別是 character varying(n) 和 character(n) 的別名。沒有長度的 character 等同於 character(1)。如果在沒有長度的情況下使用 character varying,則該型別接受任何長度的字串。後者是 PostgreSQL 延伸功能。
另外,PostgreSQL 提供了 text 型別,它儲存任意長度的字串。雖然型別 text 不在 SQL 標準中,但是其他幾個 SQL 資料庫管理系統也支援它。
character 的值用空格填充到指定的長度 n,並以這種方式儲存和顯示。但是,在比較兩個型別字串時,尾隨空格在語義上無關緊要會被忽略。在空格很重要的排序規則中,這種行為會產生意想不到的結果; 例如 SELECT 'a '::CHAR(2) collate "C"<E'a\n'::CHAR(2)
會回傳 true,即使 C 語言環境會認為空格大於換行符。將字串轉換為其他字串型別之一時,將刪除尾隨的空格。請注意,尾隨空格在 character varying 和 text 方面具有語義重要性,尤其在使用樣式匹配時,即 LIKE 和正規表示式。
短字串(126 個位元組以下)的儲存要求是 1 個位元組加上實際字串,其中包括字串空間填充。較長的字串有 4 個位元組的開銷而不是 1。長字串由系統自動壓縮,因此磁碟上的物理需求可能更少。非常長的值也儲存在後台的資料表中,這樣它們就不會干擾對較短欄位的快速存取。在任何情況下,可儲存的最長字串大約為 1 GB。(資料型別宣告中 n 允許的最大值小於此值。更改此值沒有用,因為使用多位元組字串編碼時,位元組數和字元數可能完全不同。如果您希望儲存沒有特定上限的長字串,使用不帶長度的 text 或 character varying,而不是隨便設定長度限制。)
這三種型別之間並沒有效能差異,除了使用空白填充類型時增加的儲存空間之外,以及一些額外的 CPU 週期來檢查儲存長度與欄位中的長度。雖然 character(n) 在其他一些資料庫系統中具有效能優勢,但 PostgreSQL 中並沒有這樣的優勢;事實上,由於額外的儲存成本,character(n) 通常是三者中最慢的。在大多數情況下,應使用 text 或 character varying。
有關字串文字語法的資訊,請參閱;有關可用運算子和函數的資訊,請參閱。資料庫字元集決定用於儲存文字的字元集;有關字元集支援的更多訊息,請參閱。
Example 8.1. Using the Character Types
PostgreSQL 中還有另外兩種固定長度的字串型別,如 Table 8.5 所示。name 型別僅用於在內部系統目錄中儲存指標,並非供一般使用者使用。它的長度目前定義為 64 個位元組(63 個可用字元加結尾符號),但應視 C 原始碼中的常數 NAMEDATALEN 而定。長度在編譯時設定(因此可以根據特殊用途進行調整); 預設的最大長度可能會在將來的版本中變更。型別「“char”」(注意雙引號)與 char(1) 的不同之處在於它僅使用一個位元組的儲存空間。它在系統目錄中作為簡單內部使用的列舉型別。
Table 8.5. Special Character Types
PostgreSQL 支援標準 SQL 的布林型別,如表 [Table 8-19]("DATATYPE-BOOLEAN-TABLE") 所示。布林型別有幾種狀態: "true"、"false",和第三種狀態 "unknown","unknown" 會用 SQL 的 null 值表示。
Table 8-19. 布林型別的資料型態描述
以下的字詞都可以代表 "true" 狀態:
"false" 狀態則可以用以下的字詞表示:
開頭和結尾的空白都會被忽略,也不分大小寫。 為了符合 SQL 用法,建議使用關鍵字 "TRUE" 和 "FALSE"。
[Example 8-2]("DATATYPE-BOOLEAN-EXAMPLE") 使用字母 t 和 f,來顯示布林型別的輸出。
Bit strings are strings of 1's and 0's. They can be used to store or visualize bit masks. There are two SQL bit types:bit(n)andbit varying(n), wherenis a positive integer.
bittype data must match the lengthnexactly; it is an error to attempt to store shorter or longer bit strings.bit varyingdata is of variable length up to the maximum lengthn; longer strings will be rejected. Writingbitwithout a length is equivalent tobit(1), whilebit varyingwithout a length specification means unlimited length.
Note:If one explicitly casts a bit-string value tobit(n), it will be truncated or zero-padded on the right to be exactlynbits, without raising an error. Similarly, if one explicitly casts a bit-string value tobit varying(n), it will be truncated on the right if it is more thannbits.
Refer tofor information about the syntax of bit string constants. Bit-logical operators and string manipulation functions are available; see.
Example 8-3. Using the Bit String Types
A bit string value requires 1 byte for each group of 8 bits, plus 5 or 8 bytes overhead depending on the length of the string (but long values may be compressed or moved out-of-line, as explained infor character strings).
Geometric data types represent two-dimensional spatial objects. shows the geometric types available in PostgreSQL.
Table 8.20. Geometric Types
A rich set of functions and operators is available to perform various geometric operations such as scaling, translation, rotation, and determining intersections. They are explained in .
Points are the fundamental two-dimensional building block for geometric types. Values of type point
are specified using either of the following syntaxes:
where x
and y
are the respective coordinates, as floating-point numbers.
Points are output using the first syntax.
Lines are represented by the linear equation A
x + B
y + C
= 0, where A
and B
are not both zero. Values of type line
are input and output in the following form:
Alternatively, any of the following forms can be used for input:
where (
x1
,y1
) and (
x2
,y2
) are two different points on the line.
Line segments are represented by pairs of points that are the endpoints of the segment. Values of type lseg
are specified using any of the following syntaxes:
where (
x1
,y1
) and (
x2
,y2
) are the end points of the line segment.
Line segments are output using the first syntax.
Boxes are represented by pairs of points that are opposite corners of the box. Values of type box
are specified using any of the following syntaxes:
where (
x1
,y1
) and (
x2
,y2
) are any two opposite corners of the box.
Boxes are output using the second syntax.
Any two opposite corners can be supplied on input, but the values will be reordered as needed to store the upper right and lower left corners, in that order.
Paths are represented by lists of connected points. Paths can be open, where the first and last points in the list are considered not connected, or closed, where the first and last points are considered connected.
Values of type path
are specified using any of the following syntaxes:
where the points are the end points of the line segments comprising the path. Square brackets ([]
) indicate an open path, while parentheses (()
) indicate a closed path. When the outermost parentheses are omitted, as in the third through fifth syntaxes, a closed path is assumed.
Paths are output using the first or second syntax, as appropriate.
Polygons are represented by lists of points (the vertexes of the polygon). Polygons are very similar to closed paths, but are stored differently and have their own set of support routines.
Values of type polygon
are specified using any of the following syntaxes:
where the points are the end points of the line segments comprising the boundary of the polygon.
Polygons are output using the first syntax.
Circles are represented by a center point and radius. Values of type circle
are specified using any of the following syntaxes:
where (
x
,y
) is the center point and r
is the radius of the circle.
Circles are output using the first syntax.
關於更多訊息,請參閱 。
轉譯不可列印的位元組的要求因區域設定而異。在某些情況下,你可以放棄他們而不轉譯。請注意,即使看起來有時多於一個字符, 中每個範例的結果也只有一個位元組。
如 Table 8.7 所示,需要多個倒斜線的原因是,作為字串文字編輯的輸入字串必須通過 PostgreSQL 伺服器中的兩個解析階段。每組的第一個倒斜線以字串文字解析器解釋為轉譯字元(假設使用了轉譯字串語法)並因此被消耗,留下該組的第二個倒斜線。(錢字號引用的字串可用於避免此轉譯程序。)然後,bytea 輸入函數將剩餘的倒斜線識別從三位數八進位值開始或轉譯另一個倒斜線。例如,在通過轉譯字串解析器後,作為 E'\ 001' 傳遞給伺服器的字串文字變為 \001。然後將 \001 發送到 bytea 輸入函數,在該函數中將其轉換為十進制值為 1 的單個位元組。請注意,單引號字元不受 bytea 特殊處理,因此它遵循字串文字的一般規則。(另詳見。)
bytea 位元組有時在輸出時被轉義。通常,每個「不可列印」的位元組都會轉換為等效的三位數八進位值,並以一個倒斜線開頭。大多數「可列印」位元組由它們在用戶端字元集中的標準來表示。十進位值為 92(倒斜線)的位元組在輸出中會加倍。詳情見 。
參數設定控制浮點數轉換為文字輸出時所包含的額外有效位數。使用預設值 0 時,PostgreSQL 支援的每個平台上的輸出都是相同的。增加它的話,能更精確地輸出儲存值,但可能在不同平台間是不同的結果。
本節介紹的是 PostgreSQL 專屬建立自動增量(auto-incrementing)欄位的方式。另一種方式是使用 中描述的 SQL 標準識別欄位功能。
smallserial、serial 和 bigserial,被實作來實現序列數字,即使沒有資料列被刪除,在欄位中出現的值在序列中仍可能會有「漏洞」或缺口。即使包含該值的資料列從未成功插入資料表中,從序列中分配的值仍然會用完。例如,如果資料插入的交易回溯了,則可能發生這種情況。有關詳細訊息,請參閱中的 nextval()。
日期和時間的輸入格式可以接受幾乎任何合理的格式,包括 ISO 8601、相容於 SQL 的格式、傳統 POSTGRES 格式或者其他格式。在部份格式中,日期的年、月、日的順序可能很含糊,因此有支援指定這些欄位期望的順序。可以設定 參數為 MDY
來以 月-日-年 表示、設定為 DMY
以 日-月-年 表示、或者設定為 YMD
以 年-月-日 表示。
PostgreSQL 在處理日期/時間的輸入是比 SQL 標準要求的更加靈活,關於精確的解析規則以及包含月份、一週天數、時區等可以接受的文字欄位,可以參閱。
請記得,任何日期和時間字面的輸入,都需要像文字一樣以單引號結束,詳細的資訊請參閱。SQL 要求使用以下的語法:
列出 date
型態的一些可能的輸入格式:
這些型態的合法輸入包含了一天當中的時間,以及非必須的時區。(請參照 和)。如果在 time without time zone
的輸入中指定了時區,則時區會被無聲地忽略。你也可以指定日期,但日期也會被忽略,除非你指定的時區名稱是像 America/New_York
這種具有日光節約規則的時區,因為在這種狀況下,為了能夠決定要套用一般規則或是日光節約規則,必須要有日期。適合的時差資訊會被紀錄在 time with time zone
的值當中。
關於指定時區的其他資訊,請參照。
對於帶有時區的時間戳記,內部儲存的值始終為 UTC(Universal Coordinated Time,傳統上稱為格林威治標準時間,GMT)。具有指定時區的輸入值將使用該時區的相對偏移量轉換為 UTC。如果輸入字串中未指定時區,則假定它位於系統的 參數所指示的時區中,並使用時區的偏移量轉換為 UTC。
輸出帶有時區值的時間戳記時,始終由 UTC 轉換為目前時區,並在該時區中顯示為本地時間。要查看另一個時區的時間,請變更時區或使用 AT TIME ZONE 語法(參閱)。
以下 SQL 相容函數也可用於取得相對應資料型別目前的時間值:CURRENT_DATE,CURRENT_TIME,CURRENT_TIMESTAMP,LOCALTIME,LOCALTIMESTAMP。後四者接受選擇性的 subsecond 級精確度。 (請參閱。)請注意,這些是 SQL 函數,在資料輸入字串中會無法識別。
The output format of the date/time types can be set to one of the four styles ISO 8601, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format. (The SQL standard requires the use of the ISO 8601 format. The name of the “SQL” output format is a historical accident.) shows examples of each output style. The output of the date
and time
types is generally only the date or time part in accordance with the given examples. However, the POSTGRES style outputs date-only values in ISO format.
In the SQL and POSTGRES styles, day appears before month if DMY field ordering has been specified, otherwise month appears before day. (See for how this setting also affects interpretation of input values.) shows examples.
The date/time style can be selected by the user using the SET datestyle
command, the parameter in the postgresql.conf
configuration file, or the PGDATESTYLE
environment variable on the server or client.
The formatting function to_char
(see ) is also available as a more flexible way to format date/time output.
All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the configuration parameter before being displayed to the client.
A full time zone name, for example America/New_York
. The recognized time zone names are listed in the pg_timezone_names
view (see ). PostgreSQL uses the widely-used IANA time zone data for this purpose, so the same time zone names are also recognized by much other software.
A time zone abbreviation, for example PST
. Such a specification merely defines a particular offset from UTC, in contrast to full time zone names which can imply a set of daylight savings transition-date rules as well. The recognized abbreviations are listed in the pg_timezone_abbrevs
view (see ). You cannot set the configuration parameters or to a time zone abbreviation, but you can use abbreviations in date/time input values and with the AT TIME ZONE
operator.
Neither timezone names nor abbreviations are hard-wired into the server; they are obtained from configuration files stored under .../share/timezone/
and .../share/timezonesets/
of the installation directory (see ).
The configuration parameter can be set in the file postgresql.conf
, or in any of the other standard ways described in . There are also some special ways to set it:
where quantity
is a number (possibly signed); unit
is microsecond
, millisecond
, second
, minute
, hour
, day
, week
, month
, year
, decade
, century
, millennium
, or abbreviations or plurals of these units; direction
can be ago
or empty. The at sign (@
) is optional noise. The amounts of the different units are implicitly added with appropriate sign accounting. ago
negates all the fields. This syntax is also used for interval output, if is set to postgres_verbose
.
The string must start with a P
, and may include a T
that introduces the time-of-day units. The available unit abbreviations are given in . Units may be omitted, and may be specified in any order, but units smaller than a day must appear after T
. In particular, the meaning of M
depends on whether it is before or after T
.
shows some examples of valid interval
input.
The output format of the interval type can be set to one of the four styles sql_standard
, postgres
, postgres_verbose
, or iso_8601
, using the command SET intervalstyle
. The default is the postgres
format. shows examples of each output style.
The output of the postgres
style matches the output of PostgreSQL releases prior to 8.4 when the parameter was set to ISO
.
Example 8-2. 使用布林型別
Decimal Octet Value
Description
Escaped Input Representation
Example
Output Representation
0
zero octet
E'\\000'
SELECT E'\\000'::bytea;
\000
39
single quote
''''
or E'\\047'
SELECT E'\''::bytea;
'
92
backslash
E'\\\\'
or E'\\134'
SELECT E'\\\\'::bytea;
\\
0 to 31 and 127 to 255
“non-printable” octets
E'\\
xxx'
(octal value)
SELECT E'\\001'::bytea;
\001
Decimal Octet Value
Description
Escaped Output Representation
Example
Output Result
92
backslash
\\
SELECT E'\\134'::bytea;
\\
0 to 31 and 127 to 255
“non-printable” octets
\
xxx
(octal value)
SELECT E'\\001'::bytea;
\001
32 to 126
“printable” octets
client character set representation
SELECT E'\\176'::bytea;
~
Example
Description
1999-01-08
ISO 8601; January 8 in any mode (recommended format)
January 8, 1999
unambiguous in any datestyle
input mode
1/8/1999
January 8 in MDY
mode; August 1 in DMY
mode
1/18/1999
January 18 in MDY
mode; rejected in other modes
01/02/03
January 2, 2003 in MDY
mode; February 1, 2003 in DMY
mode; February 3, 2001 in YMD
mode
1999-Jan-08
January 8 in any mode
Jan-08-1999
January 8 in any mode
08-Jan-1999
January 8 in any mode
99-Jan-08
January 8 in YMD
mode, else error
08-Jan-99
January 8, except error in YMD
mode
Jan-08-99
January 8, except error in YMD
mode
19990108
ISO 8601; January 8, 1999 in any mode
990108
ISO 8601; January 8, 1999 in any mode
1999.008
year and day of year
J2451187
Julian date
January 8, 99 BC
year 99 BC
Example
Description
04:05:06.789
ISO 8601
04:05:06
ISO 8601
04:05
ISO 8601
040506
ISO 8601
04:05 AM
same as 04:05; AM does not affect value
04:05 PM
same as 16:05; input hour must be <= 12
04:05:06.789-8
ISO 8601
04:05:06-08:00
ISO 8601
04:05-08:00
ISO 8601
040506-08
ISO 8601
04:05:06 PST
time zone specified by abbreviation
2003-04-12 04:05:06 America/New_York
time zone specified by full name
Example
Description
PST
Abbreviation (for Pacific Standard Time)
America/New_York
Full time zone name
PST8PDT
POSIX-style time zone specification
-8:00
ISO-8601 offset for PST
-800
ISO-8601 offset for PST
-8
ISO-8601 offset for PST
zulu
Military abbreviation for UTC
z
Short form of zulu
Input String
Valid Types
Description
epoch
date
, timestamp
1970-01-01 00:00:00+00 (Unix system time zero)
infinity
date
, timestamp
later than all other time stamps
-infinity
date
, timestamp
earlier than all other time stamps
now
date
, time
, timestamp
current transaction's start time
today
date
, timestamp
midnight today
tomorrow
date
, timestamp
midnight tomorrow
yesterday
date
, timestamp
midnight yesterday
allballs
time
00:00:00.00 UTC
Style Specification
Description
Example
ISO
ISO 8601, SQL standard
1997-12-17 07:37:16-08
SQL
traditional style
12/17/1997 07:37:16.00 PST
Postgres
original style
Wed Dec 17 07:37:16 1997 PST
German
regional style
17.12.1997 07:37:16.00 PST
datestyle
Setting
Input Ordering
Example Output
SQL, DMY
day
/month
/year
17/12/1997 15:37:16.00 CET
SQL, MDY
month
/day
/year
12/17/1997 07:37:16.00 PST
Postgres, DMY
day
/month
/year
Wed 17 Dec 07:37:16 1997 PST
Abbreviation
Meaning
Y
Years
M
Months (in the date part)
W
Weeks
D
Days
H
Hours
M
Minutes (in the time part)
S
Seconds
Example
Description
1-2
SQL standard format: 1 year 2 months
3 4:05:06
SQL standard format: 3 days 4 hours 5 minutes 6 seconds
1 year 2 months 3 days 4 hours 5 minutes 6 seconds
Traditional Postgres format: 1 year 2 months 3 days 4 hours 5 minutes 6 seconds
P1Y2M3DT4H5M6S
ISO 8601 “format with designators”: same meaning as above
P0001-02-03T04:05:06
ISO 8601 “alternative format”: same meaning as above
Style Specification
Year-Month Interval
Day-Time Interval
Mixed Interval
sql_standard
1-2
3 4:05:06
-1-2 +3 -4:05:06
postgres
1 year 2 mons
3 days 04:05:06
-1 year -2 mons +3 days -04:05:06
postgres_verbose
@ 1 year 2 mons
@ 3 days 4 hours 5 mins 6 secs
@ 1 year 2 mons -3 days 4 hours 5 mins 6 secs ago
iso_8601
P1Y2M
P3DT4H5M6S
P-1Y-2M3DT-4H-5M-6S
(1)
char_length 函數在 9.4 節中討論。
Name
Storage Size
Description
"char"
1 byte
單位元組內部型別
name
64 bytes
物件名稱的內部型別
Name
Storage Size
Description
boolean
1 byte
state of true or false
TRUE
't'
'true'
'y'
'yes'
'on'
'1'
FALSE
'f'
'false'
'n'
'no'
'off'
'0'
Name
Storage Size
Description
Range
money
8 bytes
currency amount
-92233720368547758.08 to +92233720368547758.07
Name
Storage Size
Description
bytea
1 or 4 bytes 加上實際的位元組字串長度
可變長度二進位字串
Name
Storage Size
Description
Range
smallint
2 bytes
small-range integer
-32768 to +32767
integer
4 bytes
typical choice for integer
-2147483648 to +2147483647
bigint
8 bytes
large-range integer
-9223372036854775808 to +9223372036854775807
decimal
variable
user-specified precision, exact
up to 131072 digits before the decimal point; up to 16383 digits after the decimal point
numeric
variable
user-specified precision, exact
up to 131072 digits before the decimal point; up to 16383 digits after the decimal point
real
4 bytes
variable-precision, inexact
6 decimal digits precision
double precision
8 bytes
variable-precision, inexact
15 decimal digits precision
smallserial
2 bytes
small autoincrementing integer
1 to 32767
serial
4 bytes
autoincrementing integer
1 to 2147483647
bigserial
8 bytes
large autoincrementing integer
1 to 9223372036854775807
Name
Storage Size
Description
Low Value
High Value
Resolution
timestamp [ (p
) ] [ without time zone ]
8 bytes
both date and time (no time zone)
4713 BC
294276 AD
1 microsecond
timestamp [ (p
) ] with time zone
8 bytes
both date and time, with time zone
4713 BC
294276 AD
1 microsecond
date
4 bytes
date (no time of day)
4713 BC
5874897 AD
1 day
time [ (p
) ] [ without time zone ]
8 bytes
time of day (no date)
00:00:00
24:00:00
1 microsecond
time [ (p
) ] with time zone
12 bytes
time of day (no date), with time zone
00:00:00+1459
24:00:00-1459
1 microsecond
interval [
fields
] [ (p
) ]
16 bytes
time interval
-178000000 years
178000000 years
1 microsecond
Name
Description
character varying(n)
, varchar(n)
可變長度,但有限制
character(n)
, char(n)
固定長度,空白填充
text
可變且無限長度
Name
Storage Size
Description
Representation
point
16 bytes
Point on a plane
(x,y)
line
32 bytes
Infinite line
{A,B,C}
lseg
32 bytes
Finite line segment
((x1,y1),(x2,y2))
box
32 bytes
Rectangular box
((x1,y1),(x2,y2))
path
16+16n bytes
Closed path (similar to polygon)
((x1,y1),...)
path
16+16n bytes
Open path
[(x1,y1),...]
polygon
40+16n bytes
Polygon (similar to closed path)
((x1,y1),...)
circle
24 bytes
Circle
<(x,y),r> (center point and radius)
The data typeuuidstores Universally Unique Identifiers (UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related standards. (Some systems refer to this data type as a globally unique identifier, or GUID, instead.) This identifier is a 128-bit quantity that is generated by an algorithm chosen to make it very unlikely that the same identifier will be generated by anyone else in the known universe using the same algorithm. Therefore, for distributed systems, these identifiers provide a better uniqueness guarantee than sequence generators, which are only unique within a single database.
A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing the 128 bits. An example of a UUID in this standard form is:
PostgreSQLalso accepts the following alternative forms for input: use of upper-case digits, the standard format surrounded by braces, omitting some or all hyphens, adding a hyphen after any group of four digits. Examples are:
Output is always in the standard form.
PostgreSQLprovides storage and comparison functions for UUIDs, but the core database does not include any function for generating UUIDs, because no single algorithm is well suited for every application. Theuuid-osspmodule provides functions that implement several standard algorithms. Thepgcryptomodule also provides a generation function for random UUIDs. Alternatively, UUIDs could be generated by client applications or other libraries invoked through a server-side function.
A_composite type_represents the structure of a row or record; it is essentially just a list of field names and their data types.PostgreSQLallows composite types to be used in many of the same ways that simple types can be used. For example, a column of a table can be declared to be of a composite type.
Here are two simple examples of defining composite types:
The syntax is comparable toCREATE TABLE
, except that only field names and types can be specified; no constraints (such asNOT NULL
) can presently be included. Note that theAS
keyword is essential; without it, the system will think a different kind ofCREATE TYPE
command is meant, and you will get odd syntax errors.
Having defined the types, we can use them to create tables:
or functions:
Whenever you create a table, a composite type is also automatically created, with the same name as the table, to represent the table's row type. For example, had we said:
then the sameinventory_item
composite type shown above would come into being as a byproduct, and could be used just as above. Note however an important restriction of the current implementation: since no constraints are associated with a composite type, the constraints shown in the table definition_do not apply_to values of the composite type outside the table. (A partial workaround is to use domain types as members of composite types.)
To write a composite value as a literal constant, enclose the field values within parentheses and separate them by commas. You can put double quotes around any field value, and must do so if it contains commas or parentheses. (More details appearbelow.) Thus, the general format of a composite constant is the following:
An example is:
which would be a valid value of theinventory_item
type defined above. To make a field be NULL, write no characters at all in its position in the list. For example, this constant specifies a NULL third field:
If you want an empty string rather than NULL, write double quotes:
Here the first field is a non-NULL empty string, the third is NULL.
(These constants are actually only a special case of the generic type constants discussed inSection 4.1.2.7. The constant is initially treated as a string and passed to the composite-type input conversion routine. An explicit type specification might be necessary to tell which type to convert the constant to.)
TheROW
expression syntax can also be used to construct composite values. In most cases this is considerably simpler to use than the string-literal syntax since you don't have to worry about multiple layers of quoting. We already used this method above:
The ROW keyword is actually optional as long as you have more than one field in the expression, so these can be simplified to:
TheROW
expression syntax is discussed in more detail inSection 4.2.13.
To access a field of a composite column, one writes a dot and the field name, much like selecting a field from a table name. In fact, it's so much like selecting from a table name that you often have to use parentheses to keep from confusing the parser. For example, you might try to select some subfields from ouron_hand
example table with something like:
This will not work since the nameitem
is taken to be a table name, not a column name ofon_hand
, per SQL syntax rules. You must write it like this:
or if you need to use the table name as well (for instance in a multitable query), like this:
Now the parenthesized object is correctly interpreted as a reference to theitem
column, and then the subfield can be selected from it.
Similar syntactic issues apply whenever you select a field from a composite value. For instance, to select just one field from the result of a function that returns a composite value, you'd need to write something like:
Without the extra parentheses, this will generate a syntax error.
The special field name*
means“all fields”, as further explained inSection 8.16.5.
Here are some examples of the proper syntax for inserting and updating composite columns. First, inserting or updating a whole column:
The first example omitsROW
, the second uses it; we could have done it either way.
We can update an individual subfield of a composite column:
Notice here that we don't need to (and indeed cannot) put parentheses around the column name appearing just afterSET
, but we do need parentheses when referencing the same column in the expression to the right of the equal sign.
And we can specify subfields as targets forINSERT
, too:
Had we not supplied values for all the subfields of the column, the remaining subfields would have been filled with null values.
There are various special syntax rules and behaviors associated with composite types in queries. These rules provide useful shortcuts, but can be confusing if you don't know the logic behind them.
InPostgreSQL, a reference to a table name (or alias) in a query is effectively a reference to the composite value of the table's current row. For example, if we had a tableinventory_item
as shownabove, we could write:
This query produces a single composite-valued column, so we might get output like:
Note however that simple names are matched to column names before table names, so this example works only because there is no column namedc
in the query's tables.
The ordinary qualified-column-name syntaxtable_name.
_column_name
_can be understood as applyingfield selectionto the composite value of the table's current row. (For efficiency reasons, it's not actually implemented that way.)
When we write
then, according to the SQL standard, we should get the contents of the table expanded into separate columns:
as if the query were
PostgreSQLwill apply this expansion behavior to any composite-valued expression, although as shownabove, you need to write parentheses around the value that.*
is applied to whenever it's not a simple table name. For example, ifmyfunc()
is a function returning a composite type with columnsa
,b
, andc
, then these two queries have the same result:
PostgreSQLhandles column expansion by actually transforming the first form into the second. So, in this example,myfunc()
would get invoked three times per row with either syntax. If it's an expensive function you may wish to avoid that, which you can do with a query like:
TheOFFSET 0
clause keeps the optimizer from“flattening”the sub-select to arrive at the form with multiple calls ofmyfunc()
.
Thecomposite_value.*
syntax results in column expansion of this kind when it appears at the top level of aSELECT
output list, aRETURNING
listinINSERT
/UPDATE
/DELETE
, aVALUES
clause, or arow constructor. In all other contexts (including when nested inside one of those constructs), attaching.*
to a composite value does not change the value, since it means“all columns”and so the same composite value is produced again. For example, ifsomefunc()
accepts a composite-valued argument, these queries are the same:
In both cases, the current row ofinventory_item
is passed to the function as a single composite-valued argument. Even though.*
does nothing in such cases, using it is good style, since it makes clear that a composite value is intended. In particular, the parser will considerc
inc.*
to refer to a table name or alias, not to a column name, so that there is no ambiguity; whereas without.*
, it is not clear whetherc
means a table name or a column name, and in fact the column-name interpretation will be preferred if there is a column namedc
.
Another example demonstrating these concepts is that all these queries mean the same thing:
All of theseORDER BY
clauses specify the row's composite value, resulting in sorting the rows according to the rules described inSection 9.23.6. However, ifinventory_item
contained a column namedc
, the first case would be different from the others, as it would mean to sort by that column only. Given the column names previously shown, these queries are also equivalent to those above:
(The last case uses a row constructor with the key wordROW
omitted.)
Another special syntactical behavior associated with composite values is that we can usefunctional notation_for extracting a field of a composite value. The simple way to explain this is that the notationsfield
(table
)andtable
.field
_are interchangeable. For example, these queries are equivalent:
Moreover, if we have a function that accepts a single argument of a composite type, we can call it with either notation. These queries are all equivalent:
This equivalence between functional notation and field notation makes it possible to use functions on composite types to implement“computed fields”.An application using the last query above wouldn't need to be directly aware thatsomefunc
isn't a real column of the table.
Because of this behavior, it's unwise to give a function that takes a single composite-type argument the same name as any of the fields of that composite type. If there is ambiguity, the field-name interpretation will be preferred, so that such a function could not be called without tricks. One way to force the function interpretation is to schema-qualify the function name, that is, writeschema
.func
(compositevalue
).
The external text representation of a composite value consists of items that are interpreted according to the I/O conversion rules for the individual field types, plus decoration that indicates the composite structure. The decoration consists of parentheses ((
and)
) around the whole value, plus commas (,
) between adjacent items. Whitespace outside the parentheses is ignored, but within the parentheses it is considered part of the field value, and might or might not be significant depending on the input conversion rules for the field data type. For example, in:
the whitespace will be ignored if the field type is integer, but not if it is text.
As shown previously, when writing a composite value you can write double quotes around any individual field value. You_must_do so if the field value would otherwise confuse the composite-value parser. In particular, fields containing parentheses, commas, double quotes, or backslashes must be double-quoted. To put a double quote or backslash in a quoted composite field value, precede it with a backslash. (Also, a pair of double quotes within a double-quoted field value is taken to represent a double quote character, analogously to the rules for single quotes in SQL literal strings.) Alternatively, you can avoid quoting and use backslash-escaping to protect all data characters that would otherwise be taken as composite syntax.
A completely empty field value (no characters at all between the commas or parentheses) represents a NULL. To write a value that is an empty string rather than NULL, write""
.
The composite output routine will put double quotes around field values if they are empty strings or contain parentheses, commas, double quotes, backslashes, or white space. (Doing so for white space is not essential, but aids legibility.) Double quotes and backslashes embedded in field values will be doubled.
Remember that what you write in an SQL command will first be interpreted as a string literal, and then as a composite. This doubles the number of backslashes you need (assuming escape string syntax is used). For example, to insert atext
field containing a double quote and a backslash in a composite value, you'd need to write:
The string-literal processor removes one level of backslashes, so that what arrives at the composite-value parser looks like("\"\\")
. In turn, the string fed to thetext
data type's input routine becomes"\
. (If we were working with a data type whose input routine also treated backslashes specially,bytea
for example, we might need as many as eight backslashes in the command to get one backslash into the stored composite field.) Dollar quoting (seeSection 4.1.2.4) can be used to avoid the need to double backslashes.
TheROW
constructor syntax is usually easier to work with than the composite-literal syntax when writing composite values in SQL commands. InROW
, individual field values are written the same way they would be written when not members of a composite.
PostgreSQLallows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type, enum type, or composite type can be created. Arrays of domains are not yet supported.
To illustrate the use of array types, we create this table:
As shown, an array data type is named by appending square brackets ([]
) to the data type name of the array elements. The above command will create a table namedsal_emp
with a column of typetext
(name
), a one-dimensional array of typeinteger
(pay_by_quarter
), which represents the employee's salary by quarter, and a two-dimensional array oftext
(schedule
), which represents the employee's weekly schedule.
The syntax forCREATE TABLE
allows the exact size of arrays to be specified, for example:
However, the current implementation ignores any supplied array size limits, i.e., the behavior is the same as for arrays of unspecified length.
The current implementation does not enforce the declared number of dimensions either. Arrays of a particular element type are all considered to be of the same type, regardless of size or number of dimensions. So, declaring the array size or number of dimensions inCREATE TABLE
is simply documentation; it does not affect run-time behavior.
An alternative syntax, which conforms to the SQL standard by using the keywordARRAY
, can be used for one-dimensional arrays.pay_by_quarter
could have been defined as:
Or, if no array size is to be specified:
As before, however,PostgreSQLdoes not enforce the size restriction in any case.
To write an array value as a literal constant, enclose the element values within curly braces and separate them by commas. (If you know C, this is not unlike the C syntax for initializing structures.) You can put double quotes around any element value, and must do so if it contains commas or curly braces. (More details appear below.) Thus, the general format of an array constant is the following:
wheredelim
_is the delimiter character for the type, as recorded in itspg_type
entry. Among the standard data types provided in thePostgreSQLdistribution, all use a comma (,
), except for typebox
which uses a semicolon (;
). Eachval
_is either a constant of the array element type, or a subarray. An example of an array constant is:
This constant is a two-dimensional, 3-by-3 array consisting of three subarrays of integers.
To set an element of an array constant to NULL, writeNULL
for the element value. (Any upper- or lower-case variant ofNULL
will do.) If you want an actual string value“NULL”, you must put double quotes around it.
(These kinds of array constants are actually only a special case of the generic type constants discussed inSection 4.1.2.7. The constant is initially treated as a string and passed to the array input conversion routine. An explicit type specification might be necessary.)
Now we can show someINSERT
statements:
The result of the previous two inserts looks like this:
Multidimensional arrays must have matching extents for each dimension. A mismatch causes an error, for example:
TheARRAY
constructor syntax can also be used:
Notice that the array elements are ordinary SQL constants or expressions; for instance, string literals are single quoted, instead of double quoted as they would be in an array literal. TheARRAY
constructor syntax is discussed in more detail inSection 4.2.12.
Now, we can run some queries on the table. First, we show how to access a single element of an array. This query retrieves the names of the employees whose pay changed in the second quarter:
The array subscript numbers are written within square brackets. By defaultPostgreSQLuses a one-based numbering convention for arrays, that is, an array ofn
_elements starts witharray[1]
and ends witharray[n
_].
This query retrieves the third quarter pay of all employees:
We can also access arbitrary rectangular slices of an array, or subarrays. An array slice is denoted by writinglower-bound
:_upper-bound
_for one or more array dimensions. For example, this query retrieves the first item on Bill's schedule for the first two days of the week:
If any dimension is written as a slice, i.e., contains a colon, then all dimensions are treated as slices. Any dimension that has only a single number (no colon) is treated as being from 1 to the number specified. For example,[2]
is treated as[1:2]
, as in this example:
To avoid confusion with the non-slice case, it's best to use slice syntax for all dimensions, e.g.,[1:2][1:1]
, not[2][1:1]
.
It is possible to omit thelower-bound
_and/orupper-bound
_of a slice specifier; the missing bound is replaced by the lower or upper limit of the array's subscripts. For example:
An array subscript expression will return null if either the array itself or any of the subscript expressions are null. Also, null is returned if a subscript is outside the array bounds (this case does not raise an error). For example, ifschedule
currently has the dimensions[1:3][1:2]
then referencingschedule[3][3]
yields NULL. Similarly, an array reference with the wrong number of subscripts yields a null rather than an error.
An array slice expression likewise yields null if the array itself or any of the subscript expressions are null. However, in other cases such as selecting an array slice that is completely outside the current array bounds, a slice expression yields an empty (zero-dimensional) array instead of null. (This does not match non-slice behavior and is done for historical reasons.) If the requested slice partially overlaps the array bounds, then it is silently reduced to just the overlapping region instead of returning null.
The current dimensions of any array value can be retrieved with thearray_dims
function:
array_dims
produces atext
result, which is convenient for people to read but perhaps inconvenient for programs. Dimensions can also be retrieved witharray_upper
andarray_lower
, which return the upper and lower bound of a specified array dimension, respectively:
array_length
will return the length of a specified array dimension:
cardinality
returns the total number of elements in an array across all dimensions. It is effectively the number of rows a call tounnest
would yield:
An array value can be replaced completely:
or using theARRAY
expression syntax:
An array can also be updated at a single element:
or updated in a slice:
The slice syntaxes with omittedlower-bound
_and/orupper-bound
_can be used too, but only when updating an array value that is not NULL or zero-dimensional (otherwise, there is no existing subscript limit to substitute).
A stored array value can be enlarged by assigning to elements not already present. Any positions between those previously present and the newly assigned elements will be filled with nulls. For example, if arraymyarray
currently has 4 elements, it will have six elements after an update that assigns tomyarray[6]
;myarray[5]
will contain null. Currently, enlargement in this fashion is only allowed for one-dimensional arrays, not multidimensional arrays.
Subscripted assignment allows creation of arrays that do not use one-based subscripts. For example one might assign tomyarray[-2:7]
to create an array with subscript values from -2 to 7.
New array values can also be constructed using the concatenation operator,||
:
The concatenation operator allows a single element to be pushed onto the beginning or end of a one-dimensional array. It also accepts twoN
-dimensional arrays, or anN
-dimensional and anN+1
-dimensional array.
When a single element is pushed onto either the beginning or end of a one-dimensional array, the result is an array with the same lower bound subscript as the array operand. For example:
When two arrays with an equal number of dimensions are concatenated, the result retains the lower bound subscript of the left-hand operand's outer dimension. The result is an array comprising every element of the left-hand operand followed by every element of the right-hand operand. For example:
When anN
-dimensional array is pushed onto the beginning or end of anN+1
-dimensional array, the result is analogous to the element-array case above. EachN
-dimensional sub-array is essentially an element of theN+1
-dimensional array's outer dimension. For example:
An array can also be constructed by using the functionsarray_prepend
,array_append
, orarray_cat
. The first two only support one-dimensional arrays, butarray_cat
supports multidimensional arrays. Some examples:
In simple cases, the concatenation operator discussed above is preferred over direct use of these functions. However, because the concatenation operator is overloaded to serve all three cases, there are situations where use of one of the functions is helpful to avoid ambiguity. For example consider:
In the examples above, the parser sees an integer array on one side of the concatenation operator, and a constant of undetermined type on the other. The heuristic it uses to resolve the constant's type is to assume it's of the same type as the operator's other input — in this case, integer array. So the concatenation operator is presumed to representarray_cat
, notarray_append
. When that's the wrong choice, it could be fixed by casting the constant to the array's element type; but explicit use ofarray_append
might be a preferable solution.
To search for a value in an array, each value must be checked. This can be done manually, if you know the size of the array. For example:
However, this quickly becomes tedious for large arrays, and is not helpful if the size of the array is unknown. An alternative method is described inSection 9.23. The above query could be replaced by:
In addition, you can find rows where the array has all values equal to 10000 with:
Alternatively, thegenerate_subscripts
function can be used. For example:
This function is described inTable 9.59.
You can also search an array using the&&
operator, which checks whether the left operand overlaps with the right operand. For instance:
This and other array operators are further described inSection 9.18. It can be accelerated by an appropriate index, as described inSection 11.2.
You can also search for specific values in an array using thearray_position
andarray_positions
functions. The former returns the subscript of the first occurrence of a value in an array; the latter returns an array with the subscripts of all occurrences of the value in the array. For example:
Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements.
The external text representation of an array value consists of items that are interpreted according to the I/O conversion rules for the array's element type, plus decoration that indicates the array structure. The decoration consists of curly braces ({
and}
) around the array value plus delimiter characters between adjacent items. The delimiter character is usually a comma (,
) but can be something else: it is determined by thetypdelim
setting for the array's element type. Among the standard data types provided in thePostgreSQLdistribution, all use a comma, except for typebox
, which uses a semicolon (;
). In a multidimensional array, each dimension (row, plane, cube, etc.) gets its own level of curly braces, and delimiters must be written between adjacent curly-braced entities of the same level.
The array output routine will put double quotes around element values if they are empty strings, contain curly braces, delimiter characters, double quotes, backslashes, or white space, or match the wordNULL
. Double quotes and backslashes embedded in element values will be backslash-escaped. For numeric data types it is safe to assume that double quotes will never appear, but for textual data types one should be prepared to cope with either the presence or absence of quotes.
By default, the lower bound index value of an array's dimensions is set to one. To represent arrays with other lower bounds, the array subscript ranges can be specified explicitly before writing the array contents. This decoration consists of square brackets ([]
) around each array dimension's lower and upper bounds, with a colon (:
) delimiter character in between. The array dimension decoration is followed by an equal sign (=
). For example:
The array output routine will include explicit dimensions in its result only when there are one or more lower bounds different from one.
If the value written for an element isNULL
(in any case variant), the element is taken to be NULL. The presence of any quotes or backslashes disables this and allows the literal string value“NULL”to be entered. Also, for backward compatibility with pre-8.2 versions ofPostgreSQL, thearray_nullsconfiguration parameter can be turnedoff
to suppress recognition ofNULL
as a NULL.
As shown previously, when writing an array value you can use double quotes around any individual array element. You_must_do so if the element value would otherwise confuse the array-value parser. For example, elements containing curly braces, commas (or the data type's delimiter character), double quotes, backslashes, or leading or trailing whitespace must be double-quoted. Empty strings and strings matching the wordNULL
must be quoted, too. To put a double quote or backslash in a quoted array element value, use escape string syntax and precede it with a backslash. Alternatively, you can avoid quotes and use backslash-escaping to protect all data characters that would otherwise be taken as array syntax.
You can add whitespace before a left brace or after a right brace. You can also add whitespace before or after any individual item string. In all of these cases the whitespace will be ignored. However, whitespace within double-quoted elements, or surrounded on both sides by non-whitespace characters of an element, is not ignored.
Remember that what you write in an SQL command will first be interpreted as a string literal, and then as an array. This doubles the number of backslashes you need. For example, to insert atext
array value containing a backslash and a double quote, you'd need to write:
The escape string processor removes one level of backslashes, so that what arrives at the array-value parser looks like{"\\","\""}
. In turn, the strings fed to thetext
data type's input routine become\
and"
respectively. (If we were working with a data type whose input routine also treated backslashes specially,bytea
for example, we might need as many as eight backslashes in the command to get one backslash into the stored array element.) Dollar quoting (seeSection 4.1.2.4) can be used to avoid the need to double backslashes.
TheARRAY
constructor syntax (seeSection 4.2.12) is often easier to work with than the array-literal syntax when writing array values in SQL commands. InARRAY
, individual element values are written the same way they would be written when not members of an array.
版本:11
Range types are data types representing a range of values of some element type (called the range's subtype). For instance, ranges of timestamp
might be used to represent the ranges of time that a meeting room is reserved. In this case the data type is tsrange
(short for “timestamp range”), and timestamp
is the subtype. The subtype must have a total order so that it is well-defined whether element values are within, before, or after a range of values.
Range types are useful because they represent many element values in a single range value, and because concepts such as overlapping ranges can be expressed clearly. The use of time and date ranges for scheduling purposes is the clearest example; but price ranges, measurement ranges from an instrument, and so forth can also be useful.
PostgreSQL comes with the following built-in range types:
int4range
— Range of integer
int8range
— Range of bigint
numrange
— Range of numeric
tsrange
— Range of timestamp without time zone
tstzrange
— Range of timestamp with time zone
daterange
— Range of date
In addition, you can define your own range types; see CREATE TYPE for more information.
See Table 9.50 and Table 9.51 for complete lists of operators and functions on range types.
Every non-empty range has two bounds, the lower bound and the upper bound. All points between these values are included in the range. An inclusive bound means that the boundary point itself is included in the range as well, while an exclusive bound means that the boundary point is not included in the range.
In the text form of a range, an inclusive lower bound is represented by “[
” while an exclusive lower bound is represented by “(
”. Likewise, an inclusive upper bound is represented by “]
”, while an exclusive upper bound is represented by “)
”. (See Section 8.17.5 for more details.)
The functions lower_inc
and upper_inc
test the inclusivity of the lower and upper bounds of a range value, respectively.
The lower bound of a range can be omitted, meaning that all points less than the upper bound are included in the range. Likewise, if the upper bound of the range is omitted, then all points greater than the lower bound are included in the range. If both lower and upper bounds are omitted, all values of the element type are considered to be in the range.
This is equivalent to considering that the lower bound is “minus infinity”, or the upper bound is “plus infinity”, respectively. But note that these infinite values are never values of the range's element type, and can never be part of the range. (So there is no such thing as an inclusive infinite bound — if you try to write one, it will automatically be converted to an exclusive bound.)
Also, some element types have a notion of “infinity”, but that is just another value so far as the range type mechanisms are concerned. For example, in timestamp ranges, [today,]
means the same thing as [today,)
. But [today,infinity]
means something different from [today,infinity)
— the latter excludes the special timestamp
value infinity
.
The functions lower_inf
and upper_inf
test for infinite lower and upper bounds of a range, respectively.
The input for a range value must follow one of the following patterns:
The parentheses or brackets indicate whether the lower and upper bounds are exclusive or inclusive, as described previously. Notice that the final pattern is empty
, which represents an empty range (a range that contains no points).
The lower-bound
may be either a string that is valid input for the subtype, or empty to indicate no lower bound. Likewise, upper-bound
may be either a string that is valid input for the subtype, or empty to indicate no upper bound.
Each bound value can be quoted using "
(double quote) characters. This is necessary if the bound value contains parentheses, brackets, commas, double quotes, or backslashes, since these characters would otherwise be taken as part of the range syntax. To put a double quote or backslash in a quoted bound value, precede it with a backslash. (Also, a pair of double quotes within a double-quoted bound value is taken to represent a double quote character, analogously to the rules for single quotes in SQL literal strings.) Alternatively, you can avoid quoting and use backslash-escaping to protect all data characters that would otherwise be taken as range syntax. Also, to write a bound value that is an empty string, write ""
, since writing nothing means an infinite bound.
Whitespace is allowed before and after the range value, but any whitespace between the parentheses or brackets is taken as part of the lower or upper bound value. (Depending on the element type, it might or might not be significant.)
These rules are very similar to those for writing field values in composite-type literals. See Section 8.16.6 for additional commentary.
Examples:
Each range type has a constructor function with the same name as the range type. Using the constructor function is frequently more convenient than writing a range literal constant, since it avoids the need for extra quoting of the bound values. The constructor function accepts two or three arguments. The two-argument form constructs a range in standard form (lower bound inclusive, upper bound exclusive), while the three-argument form constructs a range with bounds of the form specified by the third argument. The third argument must be one of the strings “()
”, “(]
”, “[)
”, or “[]
”. For example:
A discrete range is one whose element type has a well-defined “step”, such as integer
or date
. In these types two elements can be said to be adjacent, when there are no valid values between them. This contrasts with continuous ranges, where it's always (or almost always) possible to identify other element values between two given values. For example, a range over the numeric
type is continuous, as is a range over timestamp
. (Even though timestamp
has limited precision, and so could theoretically be treated as discrete, it's better to consider it continuous since the step size is normally not of interest.)
Another way to think about a discrete range type is that there is a clear idea of a “next” or “previous” value for each element value. Knowing that, it is possible to convert between inclusive and exclusive representations of a range's bounds, by choosing the next or previous element value instead of the one originally given. For example, in an integer range type [4,8]
and (3,9)
denote the same set of values; but this would not be so for a range over numeric.
A discrete range type should have a canonicalization function that is aware of the desired step size for the element type. The canonicalization function is charged with converting equivalent values of the range type to have identical representations, in particular consistently inclusive or exclusive bounds. If a canonicalization function is not specified, then ranges with different formatting will always be treated as unequal, even though they might represent the same set of values in reality.
The built-in range types int4range
, int8range
, and daterange
all use a canonical form that includes the lower bound and excludes the upper bound; that is, [)
. User-defined range types can use other conventions, however.
Users can define their own range types. The most common reason to do this is to use ranges over subtypes not provided among the built-in range types. For example, to define a new range type of subtype float8
:
Because float8
has no meaningful “step”, we do not define a canonicalization function in this example.
Defining your own range type also allows you to specify a different subtype B-tree operator class or collation to use, so as to change the sort ordering that determines which values fall into a given range.
If the subtype is considered to have discrete rather than continuous values, the CREATE TYPE
command should specify a canonical
function. The canonicalization function takes an input range value, and must return an equivalent range value that may have different bounds and formatting. The canonical output for two ranges that represent the same set of values, for example the integer ranges [1, 7]
and [1, 8)
, must be identical. It doesn't matter which representation you choose to be the canonical one, so long as two equivalent values with different formattings are always mapped to the same value with the same formatting. In addition to adjusting the inclusive/exclusive bounds format, a canonicalization function might round off boundary values, in case the desired step size is larger than what the subtype is capable of storing. For instance, a range type over timestamp
could be defined to have a step size of an hour, in which case the canonicalization function would need to round off bounds that weren't a multiple of an hour, or perhaps throw an error instead.
In addition, any range type that is meant to be used with GiST or SP-GiST indexes should define a subtype difference, or subtype_diff
, function. (The index will still work without subtype_diff
, but it is likely to be considerably less efficient than if a difference function is provided.) The subtype difference function takes two input values of the subtype, and returns their difference (i.e., X
minus Y
) represented as a float8
value. In our example above, the function float8mi
that underlies the regular float8
minus operator can be used; but for any other subtype, some type conversion would be necessary. Some creative thought about how to represent differences as numbers might be needed, too. To the greatest extent possible, the subtype_diff
function should agree with the sort ordering implied by the selected operator class and collation; that is, its result should be positive whenever its first argument is greater than its second according to the sort ordering.
A less-oversimplified example of a subtype_diff
function is:
See CREATE TYPE for more information about creating range types.
GiST and SP-GiST indexes can be created for table columns of range types. For instance, to create a GiST index:
A GiST or SP-GiST index can accelerate queries involving these range operators: =
, &&
, <@
, @>
, <<
, >>
, -|-
, &<
, and &>
(see Table 9.50 for more information).
In addition, B-tree and hash indexes can be created for table columns of range types. For these index types, basically the only useful range operation is equality. There is a B-tree sort ordering defined for range values, with corresponding <
and >
operators, but the ordering is rather arbitrary and not usually useful in the real world. Range types' B-tree and hash support is primarily meant to allow sorting and hashing internally in queries, rather than creation of actual indexes.
While UNIQUE
is a natural constraint for scalar values, it is usually unsuitable for range types. Instead, an exclusion constraint is often more appropriate (see CREATE TABLE ... CONSTRAINT ... EXCLUDE). Exclusion constraints allow the specification of constraints such as “non-overlapping” on a range type. For example:
That constraint will prevent any overlapping values from existing in the table at the same time:
You can use the btree_gist
extension to define exclusion constraints on plain scalar data types, which can then be combined with range exclusions for maximum flexibility. For example, after btree_gist
is installed, the following constraint will reject overlapping ranges only if the meeting room numbers are equal:
JSON data types are for storing JSON (JavaScript Object Notation) data, as specified inRFC 7159. Such data can also be stored astext
, but the JSON data types have the advantage of enforcing that each stored value is valid according to the JSON rules. There are also assorted JSON-specific functions and operators available for data stored in these data types; seeSection 9.15.
There are two JSON data types:json
andjsonb
. They accept_almost_identical sets of values as input. The major practical difference is one of efficiency. Thejson
data type stores an exact copy of the input text, which processing functions must reparse on each execution; whilejsonb
data is stored in a decomposed binary format that makes it slightly slower to input due to added conversion overhead, but significantly faster to process, since no reparsing is needed.jsonb
also supports indexing, which can be a significant advantage.
Because thejson
type stores an exact copy of the input text, it will preserve semantically-insignificant white space between tokens, as well as the order of keys within JSON objects. Also, if a JSON object within the value contains the same key more than once, all the key/value pairs are kept. (The processing functions consider the last value as the operative one.) By contrast,jsonb
does not preserve white space, does not preserve the order of object keys, and does not keep duplicate object keys. If duplicate keys are specified in the input, only the last value is kept.
In general, most applications should prefer to store JSON data asjsonb
, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys.
PostgreSQLallows only one character set encoding per database. It is therefore not possible for the JSON types to conform rigidly to the JSON specification unless the database encoding is UTF8. Attempts to directly include characters that cannot be represented in the database encoding will fail; conversely, characters that can be represented in the database encoding but not in UTF8 will be allowed.
RFC 7159 permits JSON strings to contain Unicode escape sequences denoted by\uXXXX
. In the input function for thejson
type, Unicode escapes are allowed regardless of the database encoding, and are checked only for syntactic correctness (that is, that four hex digits follow\u
). However, the input function forjsonb
is stricter: it disallows Unicode escapes for non-ASCII characters (those aboveU+007F
) unless the database encoding is UTF8. Thejsonb
type also rejects\u0000
(because that cannot be represented inPostgreSQL'stext
type), and it insists that any use of Unicode surrogate pairs to designate characters outside the Unicode Basic Multilingual Plane be correct. Valid Unicode escapes are converted to the equivalent ASCII or UTF8 character for storage; this includes folding surrogate pairs into a single character.
Many of the JSON processing functions described inSection 9.15will convert Unicode escapes to regular characters, and will therefore throw the same types of errors just described even if their input is of typejson
notjsonb
. The fact that thejson
input function does not make these checks may be considered a historical artifact, although it does allow for simple storage (without processing) of JSON Unicode escapes in a non-UTF8 database encoding. In general, it is best to avoid mixing Unicode escapes in JSON with a non-UTF8 database encoding, if possible.
When converting textual JSON input intojsonb
, the primitive types described byRFC7159 are effectively mapped onto nativePostgreSQLtypes, as shown inTable 8.23. Therefore, there are some minor additional constraints on what constitutes validjsonb
data that do not apply to thejson
type, nor to JSON in the abstract, corresponding to limits on what can be represented by the underlying data type. Notably,jsonb
will reject numbers that are outside the range of thePostgreSQLnumeric
data type, whilejson
will not. Such implementation-defined restrictions are permitted byRFC7159. However, in practice such problems are far more likely to occur in other implementations, as it is common to represent JSON'snumber
primitive type as IEEE 754 double precision floating point (whichRFC7159 explicitly anticipates and allows for). When using JSON as an interchange format with such systems, the danger of losing numeric precision compared to data originally stored byPostgreSQLshould be considered.
Conversely, as noted in the table there are some minor restrictions on the input format of JSON primitive types that do not apply to the correspondingPostgreSQLtypes.
Table 8.23. JSON primitive types and correspondingPostgreSQLtypes
JSON primitive type
PostgreSQL
type
Notes
string
text
\u0000
is disallowed, as are non-ASCII Unicode escapes if database encoding is not UTF8
number
numeric
NaN
andinfinity
values are disallowed
boolean
boolean
Only lowercasetrue
andfalse
spellings are accepted
null
(none)
SQLNULL
is a different concept
The input/output syntax for the JSON data types is as specified inRFC7159.
The following are all validjson
(orjsonb
) expressions:
As previously stated, when a JSON value is input and then printed without any additional processing,json
outputs the same text that was input, whilejsonb
does not preserve semantically-insignificant details such as whitespace. For example, note the differences here:
One semantically-insignificant detail worth noting is that injsonb
, numbers will be printed according to the behavior of the underlyingnumeric
type. In practice this means that numbers entered withE
notation will be printed without it, for example:
However,jsonb
will preserve trailing fractional zeroes, as seen in this example, even though those are semantically insignificant for purposes such as equality checks.
Representing data as JSON can be considerably more flexible than the traditional relational data model, which is compelling in environments where requirements are fluid. It is quite possible for both approaches to co-exist and complement each other within the same application. However, even for applications where maximal flexibility is desired, it is still recommended that JSON documents have a somewhat fixed structure. The structure is typically unenforced (though enforcing some business rules declaratively is possible), but having a predictable structure makes it easier to write queries that usefully summarize a set of“documents”(datums) in a table.
JSON data is subject to the same concurrency-control considerations as any other data type when stored in a table. Although storing large documents is practicable, keep in mind that any update acquires a row-level lock on the whole row. Consider limiting JSON documents to a manageable size in order to decrease lock contention among updating transactions. Ideally, JSON documents should each represent an atomic datum that business rules dictate cannot reasonably be further subdivided into smaller datums that could be modified independently.
jsonb
Containment and ExistenceTesting_containment_is an important capability ofjsonb
. There is no parallel set of facilities for thejson
type. Containment tests whether onejsonb
document has contained within it another one. These examples return true except as noted:
The general principle is that the contained object must match the containing object as to structure and data contents, possibly after discarding some non-matching array elements or object key/value pairs from the containing object. But remember that the order of array elements is not significant when doing a containment match, and duplicate array elements are effectively considered only once.
As a special exception to the general principle that the structures must match, an array may contain a primitive value:
jsonb
also has an_existence_operator, which is a variation on the theme of containment: it tests whether a string (given as atext
value) appears as an object key or array element at the top level of thejsonb
value. These examples return true except as noted:
JSON objects are better suited than arrays for testing containment or existence when there are many keys or elements involved, because unlike arrays they are internally optimized for searching, and do not need to be searched linearly.
Because JSON containment is nested, an appropriate query can skip explicit selection of sub-objects. As an example, suppose that we have adoc
column containing objects at the top level, with most objects containingtags
fields that contain arrays of sub-objects. This query finds entries in which sub-objects containing both"term":"paris"
and"term":"food"
appear, while ignoring any such keys outside thetags
array:
One could accomplish the same thing with, say,
but that approach is less flexible, and often less efficient as well.
On the other hand, the JSON existence operator is not nested: it will only look for the specified key or array element at top level of the JSON value.
The various containment and existence operators, along with all other JSON operators and functions are documented inSection 9.15.
jsonb
IndexingGIN indexes can be used to efficiently search for keys or key/value pairs occurring within a large number ofjsonb
documents (datums). Two GIN“operator classes”are provided, offering different performance and flexibility trade-offs.
The default GIN operator class forjsonb
supports queries with top-level key-exists operators?
,?&
and?|
operators and path/value-exists operator@>
. (For details of the semantics that these operators implement, seeTable 9.44.) An example of creating an index with this operator class is:
The non-default GIN operator classjsonb_path_ops
supports indexing the@>
operator only. An example of creating an index with this operator class is:
Consider the example of a table that stores JSON documents retrieved from a third-party web service, with a documented schema definition. A typical document is:
We store these documents in a table namedapi
, in ajsonb
column namedjdoc
. If a GIN index is created on this column, queries like the following can make use of the index:
However, the index could not be used for queries like the following, because though the operator?
is indexable, it is not applied directly to the indexed columnjdoc
:
Still, with appropriate use of expression indexes, the above query can use an index. If querying for particular items within the"tags"
key is common, defining an index like this may be worthwhile:
Now, theWHERE
clausejdoc -> 'tags' ? 'qui'
will be recognized as an application of the indexable operator?
to the indexed expressionjdoc -> 'tags'
. (More information on expression indexes can be found inSection 11.7.)
Another approach to querying is to exploit containment, for example:
A simple GIN index on thejdoc
column can support this query. But note that such an index will store copies of every key and value in thejdoc
column, whereas the expression index of the previous example stores only data found under thetags
key. While the simple-index approach is far more flexible (since it supports queries about any key), targeted expression indexes are likely to be smaller and faster to search than a simple index.
Although thejsonb_path_ops
operator class supports only queries with the@>
operator, it has notable performance advantages over the default operator classjsonb_ops
. Ajsonb_path_ops
index is usually much smaller than ajsonb_ops
index over the same data, and the specificity of searches is better, particularly when queries contain keys that appear frequently in the data. Therefore search operations typically perform better than with the default operator class.
The technical difference between ajsonb_ops
and ajsonb_path_ops
GIN index is that the former creates independent index items for each key and value in the data, while the latter creates index items only for each value in the data.[6]Basically, eachjsonb_path_ops
index item is a hash of the value and the key(s) leading to it; for example to index{"foo": {"bar": "baz"}}
, a single index item would be created incorporating all three offoo
,bar
, andbaz
into the hash value. Thus a containment query looking for this structure would result in an extremely specific index search; but there is no way at all to find out whetherfoo
appears as a key. On the other hand, ajsonb_ops
index would create three index items representingfoo
,bar
, andbaz
separately; then to do the containment query, it would look for rows containing all three of these items. While GIN indexes can perform such an AND search fairly efficiently, it will still be less specific and slower than the equivalentjsonb_path_ops
search, especially if there are a very large number of rows containing any single one of the three index items.
A disadvantage of thejsonb_path_ops
approach is that it produces no index entries for JSON structures not containing any values, such as{"a": {}}
. If a search for documents containing such a structure is requested, it will require a full-index scan, which is quite slow.jsonb_path_ops
is therefore ill-suited for applications that often perform such searches.
jsonb
also supportsbtree
andhash
indexes. These are usually useful only if it's important to check equality of complete JSON documents. Thebtree
ordering forjsonb
datums is seldom of great interest, but for completeness it is:
Objects with equal numbers of pairs are compared in the order:
Note that object keys are compared in their storage order; in particular, since shorter keys are stored before longer keys, this can lead to results that might be unintuitive, such as:
Similarly, arrays with equal numbers of elements are compared in the order:
Primitive JSON values are compared using the same comparison rules as for the underlyingPostgreSQLdata type. Strings are compared using the default database collation.
[6]For this purpose, the term“value”includes array elements, though JSON terminology sometimes considers array elements distinct from values within objects.
Object identifiers (OIDs) are used internally byPostgreSQLas primary keys for various system tables. OIDs are not added to user-created tables, unlessWITH OIDS
is specified when the table is created, or thedefault_with_oidsconfiguration variable is enabled. Typeoid
represents an object identifier. There are also several alias types foroid
:regproc
,regprocedure
,regoper
,regoperator
,regclass
,regtype
,regrole
,regnamespace
,regconfig
, andregdictionary
.Table 8.24shows an overview.
Theoid
type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.
Theoid
type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)
The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that typeoid
would use. The alias types allow simplified lookup of OID values for objects. For example, to examine thepg_attribute
rows related to a tablemytable
, one could write:
rather than:
While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables namedmytable
in different schemas. Theregclass
input converter handles the table lookup according to the schema path setting, and so it does the“right thing”automatically. Similarly, casting a table's OID toregclass
is handy for symbolic display of a numeric OID.
Table 8.24. Object Identifier Types
Name
References
Description
Value Example
oid
any
numeric object identifier
564182
regproc
pg_proc
function name
sum
regprocedure
pg_proc
function with argument types
sum(int4)
regoper
pg_operator
operator name
+
regoperator
pg_operator
operator with argument types
*(integer,integer)
or-(NONE,integer)
regclass
pg_class
relation name
pg_type
regtype
pg_type
data type name
integer
regrole
pg_authid
role name
smithee
regnamespace
pg_namespace
namespace name
pg_catalog
regconfig
pg_ts_config
text search configuration
english
regdictionary
pg_ts_dict
text search dictionary
simple
All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. Theregproc
andregoper
alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most usesregprocedure
orregoperator
are more appropriate. Forregoperator
, unary operators are identified by writingNONE
for the unused operand.
An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expressionnextval('my_seq'::regclass)
,PostgreSQLunderstands that the default expression depends on the sequencemy_seq
; the system will not let the sequence be dropped without first removing the default expression.regrole
is the only exception for the property. Constants of this type are not allowed in such expressions.
The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning.
Another identifier type used by the system isxid
, or transaction (abbreviatedxact) identifier. This is the data type of the system columnsxmin
andxmax
. Transaction identifiers are 32-bit quantities.
A third identifier type used by the system iscid
, or command identifier. This is the data type of the system columnscmin
andcmax
. Command identifiers are also 32-bit quantities.
A final identifier type used by the system istid
, or tuple identifier (row identifier). This is the data type of the system columnctid
. A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table.
(The system columns are further explained inSection 5.4.)
本使用手冊由台灣 PostgreSQL 社群提供,翻譯自 PostgreSQL 官方使用手冊,以推廣 PostgreSQL 於台灣的應用。
本使用手冊目前編譯內容為 PostgreSQL 11,另外還有 FAQ 可以參考。
每一個頁面均附上官方手冊對應連結,翻譯未詳盡之處,可對照閱讀。 未翻譯完成之段落,將暫以原文(英文)替代。
閱讀前,也可以參閱摘要簡報: https://gitpitch.com/pgsql-tw/twpug-doc
目前最新版本為 PostgreSQL 11:(部份內容為版本10,持續更新中) https://medium.com/pgsql-tw/postgresql-11-press-kit-331df8357dcc
參與協作請在任何頁面,點選右上角的「Edit on GitHub」,修改後直接送 PR 給我們即可。 (只翻一句也可以唷!)
任何問題或建議可以 Email 給我們的文件小組:docs@postgresql.tw
PostgreSQL 為內建的資料型別提供了大量的函數和運算子。使用者還可以定義自己的函數和運算子,如第 V 部分所述。psql 指令 \df 和 \do 可分別用於列出所有可用的函數和運算子。
如果您擔心可移植性,那麼請注意,本章中描述的大多數函數和運算子(最常見的算術運算子和比較運算子以及一些明確標記的函數除外)都不是由 SQL 標準指定的。其他一些 SQL 資料庫管理系統提供了其中一些延伸功能,並且在許多情況下,這些功能在各種實作之間是相容和一致的。本章可能不夠完整;附加功能出現在手冊的其他相關章節中。
Thepg_lsn
data type can be used to store LSN (Log Sequence Number) data which is a pointer to a location in the WAL. This type is a representation ofXLogRecPtr
and an internal system type ofPostgreSQL.
Internally, an LSN is a 64-bit integer, representing a byte position in the write-ahead log stream. It is printed as two hexadecimal numbers of up to 8 digits each, separated by a slash; for example,16/B374D848
. Thepg_lsn
type supports the standard comparison operators, like=
and>
. Two LSNs can be subtracted using the-
operator; the result is the number of bytes separating those write-ahead log locations.
The usual logical operators are available:
AND
OR
NOT
SQLuses a three-valued logic system with true, false, andnull
, which represents“unknown”. Observe the following truth tables:
a
b
a
AND
b
a
OR
b
TRUE
TRUE
TRUE
TRUE
TRUE
FALSE
FALSE
TRUE
TRUE
NULL
NULL
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
NULL
FALSE
NULL
NULL
NULL
NULL
NULL
a
NOT
a
TRUE
FALSE
FALSE
TRUE
NULL
NULL
The operatorsAND
andOR
are commutative, that is, you can switch the left and right operand without affecting the result. But seeSection 4.2.14for more information about the order of evaluation of subexpressions.
ThePostgreSQLtype system contains a number of special-purpose entries that are collectively calledpseudo-types. A pseudo-type cannot be used as a column data type, but it can be used to declare a function's argument or result type. Each of the available pseudo-types is useful in situations where a function's behavior does not correspond to simply taking or returning a value of a specificSQLdata type.Table 8.25lists the existing pseudo-types.
Table 8.25. Pseudo-Types
Name
Description
any
Indicates that a function accepts any input data type.
anyelement
anyarray
anynonarray
anyenum
anyrange
cstring
Indicates that a function accepts or returns a null-terminated C string.
internal
Indicates that a function accepts or returns a server-internal data type.
language_handler
A procedural language call handler is declared to returnlanguage_handler
.
fdw_handler
A foreign-data wrapper handler is declared to returnfdw_handler
.
index_am_handler
An index access method handler is declared to returnindex_am_handler
.
tsm_handler
A tablesample method handler is declared to returntsm_handler
.
record
Identifies a function taking or returning an unspecified row type.
trigger
A trigger function is declared to returntrigger.
event_trigger
An event trigger function is declared to returnevent_trigger.
pg_ddl_command
Identifies a representation of DDL commands that is available to event triggers.
void
Indicates that a function returns no value.
unknown
Identifies a not-yet-resolved type, e.g. of an undecorated string literal.
opaque
An obsolete type name that formerly served many of the above purposes.
Functions coded in C (whether built-in or dynamically loaded) can be declared to accept or return any of these pseudo data types. It is up to the function author to ensure that the function will behave safely when a pseudo-type is used as an argument type.
Functions coded in procedural languages can use pseudo-types only as allowed by their implementation languages. At present most procedural languages forbid use of a pseudo-type as an argument type, and allow onlyvoid
andrecord
as a result type (plustrigger
orevent_trigger
when the function is used as a trigger or event trigger). Some also support polymorphic functions using the typesanyelement
,anyarray
,anynonarray
,anyenum
, andanyrange
.
Theinternal
pseudo-type is used to declare functions that are meant only to be called internally by the database system, and not by direct invocation in anSQLquery. If a function has at least oneinternal
-type argument then it cannot be called fromSQL. To preserve the type safety of this restriction it is important to follow this coding rule: do not create any function that is declared to returninternal
unless it has at least oneinternal
argument.
參數表示式用在許多不同的方面,像是 SELECT 指令中的回傳列表;在 INSERT 或 UPDATE 指令中指定欄位的新值;又或是在一些命令中,指出搜尋的條件等。參數表示式的結果,有時候會被稱作 scalar,以有別於表格表示式(就是一個表格)的結果。參數表示式也可以稱作 scalar expressions(賦值表示式),甚或簡化為 expressions (表示式)。表示式的語法容許其值為各種運算的單一結果,如數學、邏輯、集合、或其他運算。
參數表示式可以是下列的其中一種形態:
常數或文字內容
欄位的引用
函數參數的引用,在函數裡或預備指令(prepared statement)中
子參數表示式
欄位選擇表示式
運算子宣告
函數呼叫
彙總表示式
窗函數呼叫
型別轉換
校對轉換(collation expression)
賦值子查詢(scalar subquery)
陣列建構式
列建構式
其他被括號括住的參數表示式(用於群組子表示式和強制調整運算優先權)
要引要一個欄位的話,請使用下列的形式:
函數參數的引用,用來指定一個不在該 SQL 指令中的值。參數是使用在 SQL 函數定義或預備查詢之中。有一些用戶端函式庫也支援將資料數值與 SQL 指令分離,在這種情境下,參數就會用來指向外部的資料數值。參數引用的形式如下:
舉個例子,有一個函數 dept 的宣告如下:
這裡的 $1 指的是函數被呼叫時的第 1 個輸入參數:
如果表示式要產生陣列的結果的話,指定陣列中某個元素,請使用:
或是要取得陣列中多個相隣的元素,請使用:
每一個「subscript」本身都是一個表示式,必須要產生一個整數值。
一般來說,陣列表示式必須被括號起來,但如果該表示式只是一個欄位或參數的引用的話,那麼括號可以省略。然後,多個子參數表示式可以連在一起使用,當你需要陣列表達多維度的概念時。舉例如下:
如果一個表示式產生了複合性的型別(列型別),那麼要指定其中的某個欄位時,請使用:
一般來說,列的表示式必須被括號起來,但如果該表示式只是一個欄位或參數的引用的話,那麼括號可以省略。舉例如下:
(然而,有限制的欄位引用,實際上就是一種欄位選擇語法的特列。)有一種重要的特例是從某個複合型別的表格欄位中取其子欄位的值:
在這裡,括號是必要的,以表示 compositecol 是一個欄位名稱,但不是表格名稱。而在第二個例子中,mytable 是表格名稱,而非結構名稱。
你可以取得複合資料的所有欄位值,使用「.*」:
有三種用來進行運算子宣告的語法:
函數呼叫的語法是,函數的名稱(可能還會加上結構名)接著一連串用括號括起來的參數列表:
舉個例子,下面的函數呼叫可以計算 2 的平方根:
彙總表示式用在查詢時,過濾資料進行彙總函數計算的應用。彙總函數壓縮了大量資料輸入成為一個單一的輸出值,例如加總或平均數。彙總表示式的語法可以是下列其中之一:
這裡的 agregate_name 是預先就定義好的(可能還需要加上結構名稱),表示式可以是任何的函數形態,但不能包含彙總函數或窗函數。而 order_by_clause 和 filter_clause 後續進行說明。
第一種形式的彙總表示式用於每次輸入一列的情況;第二種形式和第一種相同,當 ALL 是預設的時候;第三種形式彙總不重覆的資料(或在多種表示式的時候,取不重覆的集合);第四種形式也是每次輸入一列,但沒有限定輸入條件,通常是用於 count(*);最後一種形式用於有次序的彙總函數,稍後說明。
大多數的彙總函數會忽略空值,所以如果表示式計算的結果是空值的話,就會忽略不計。這樣的假設除非有特別設定,對所有內建的函數都是如此。
舉例來說,count(*) 計算輸入列的個數,而 count(f1) 是計算輸入列中 f1 欄位非空值的個數,因為 count 會忽略空值;然而,count(distinct f1) 則是計算 f1 欄位不重覆又非空值的個數。
通常彙總函數在處理輸入資料時,都是未排序過的。在大多數的情況沒有關係,例如:min 最小值的計算,與其輸入的次序沒有關係。然而,還是有些彙總函數的結果,與其處理次序是有關連的,例如:array_agg 和 string_agg。ORDER BY 字句就可以達到此效果,其與一般查詢語法 ORDER BY 的用法相同,詳細說明在 7.5 節,除非該表示式無法輸出成欄位名稱或數字。舉例如下:
操作到多參數的彙總函數時,注意 ORDER BY 會處理過所有的彙總參數,例如:
但不能這樣寫:
這在語法上沒有不合法,但這表示一個單參數的彙總函數,使用了兩個排序的關鍵值(第二個完全沒用,因為它是常數)。
如果 DISTINCT 被加到 ORDER BY 子句裡的話,那麼所有的 ORDER BY 表示式都必須符合彙總函數的參數,也就是說,你不能使用不在 DISTINCT 列表中的表示式來排序。
在彙總函數中使用 DISTINCT 和 ORDER BY,都是 PostgreSQL 的延伸。
把 ORDER BY 放進彙總函數的參數列表中,就如同到目前為止的描述,用於排序輸入值,進行一般性的處理或統計彙總,而排序是選擇性的。有另一種類型的彙總函數稱作有次序彙總,它們就必須要有 ORDER BY 子句,通常就是因為這些函數的計算結果,只會對某些特定次序的資料產生效果。典型的有次序彙總例子,包含排名和累計百分比計算。對於有次序彙總計算,將 ORDER BY 字句寫進 WITHIN GROUP (...) 中,如同上述最後一個語法例子。在 ORDER BY 子句中的表示式會處理每一筆輸入資料,如同一般的彚總函數,然後將其依子句中的表示式計算並排序,最後再依序轉送給彙總函數處理。(這和非處理 WITHIN GROUP 中的 ORDER BY 不同,它們不會再轉送給彙總函數。)如果有在 WITHIN GROUP 之前的表示式的話,稱作直接參數,會和有 ORDER BY 的參數有區分。不像一般的彙總參數,直接參數只會被處理一次,而不是每一筆都一次。這意思是只有在 GROUP BY 中,這些變數才會被彙總處理。這樣的限制就如同直接參數不在彙總表示式之中一樣。直接參數一般用於累計分配,只有在每一次彙整完的值才有意義。直接參數可以是空值,在這個例子中,使用的是 (),而非 (*)。(PostgreSQL 兩種寫法都可以接受,但標準 SQL 只接受前者。)
有次序彙總查詢如下:
這裡包含了 50% 的累計,或是中間數累計,來源是表格 households 的 income 欄位。其中,0.5 是直接參數,它不影響百分累計彙整計算過程。
如果使用了 FILTER,那就只有符合 FILTER 子句條件的資料會被彙總處理,其他的資料都會被忽略掉。舉例來說:
彙總表示式只可以用於結果列表或 SELECT 中的 HAVING 子句。在其他子句中是被禁止的,像是 WHERE,因為這些子句邏輯上都是在彙總處理前就得處理資料。
窗函數呼叫指的是使用類似彙總函數的使用方式,只是僅用於查詢中部份列的選擇上。和非窗函數不同的是,這並不會只輸出為單一列—每一列都仍然分開輸出。然而,窗函數也是處理了所有該列所屬群組的其他列(PARTITION BY),依其窗函數所定義的範圍。窗函數呼叫的方式可以是下列其中之一:
定義「窗」,請使用下列語法:
選擇性的 frame_clause 語法如下:
frame_start 及 frame_end 的語法如下:
在這裡的表示式(expression),除了不能再包含窗函數之外,無其他特別限制。
PARTITION BY 子句將查詢分組成為不同的分區,它們將會分別地被窗函數所處理。PARTITION BY 的行為和查詢語句中的 GROUP BY 很類似,除了它的表示式就只是表示式,而且不能產出欄位名稱或編號。沒有 PARTITION BY 的話,所有的列都會被當作一個分組進行彙總。ORDER BY 子句決定窗函數的處理次序,它也和查詢語句中的 ORDER BY 很類似,但它不能使用輸出的欄位或編號。如果沒有 ORDER BY 的話,就無法保證彙總處理的次序了。
frame_clause 指的是構成該窗的列,再進一步以「窗框」拆分,是目前分區的子集合。對窗函數而言,運算會以窗框的範圍取代整合分區。窗框的指定可以是 RANGE 或 ROW 兩種模式。不論哪種模式,都 frame_start 執行到 frame_end,但如果 frame_end 省略了,預設就是到目前的列(CURRENT ROW)。
UNBOUNDED PRECEDING 的窗框始於該分區的第一列,同樣地,UNBOUNDED FOLLOWING 意指窗框結束於分區的最後一列。
在 RANGE 模式裡,如果 frame_start 設定為 CURRENT ROW 的話,表示窗框始於目前列同序的那一列(使用 ORDER BY 時,排序相同的那一列),同理,frame_end 設定為 CURRENT ROW 時,表示窗框止於排序相同的列。而在 ROWS 模式時,CURRENT ROW 指的就是自己。
PRECEDING 和 FOLLOWING 兩個設定值,目前只能用在 ROWS 模式。它們指的是窗框的起迄於指定的一個值,表示目前列之前後多少列。而所謂的值,必須是整數表示式而不包含任何變數、彙總函數、或窗函數。其值也不能是空值或負值,但可以為零,表示只處理目前列。
預設的窗框設定是 RANGE UNBOUNDED PRECEDING,和 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是一樣的。加上 ORDER BY 的話,這可以讓窗框起於和目前列並列的列;沒有 ORDER BY 的話,所有的列都會在分區裡,因為如此就無法判定次序,表示大家都一樣。
frame_start 的限制是不能使用 UNBOUNDED FOLLOWING,而 frame_end 不能使用 UNBOUNDED PRECEDING。frame_end 的設定也不能先於 frame_start—舉例來說,RANGE BETWEEN CURRENT ROW,使用 PRECEDING 就不可以。
如果有使用到 FILTER 的話,就只有符合 FILTER 條件式的列會被窗函數處理,其餘的列都會被忽略。只有彙總式的窗函數可以使用 FILTER 子句。
「*」語法的使用,用來把無參數的彙總函數當作窗函數來使用,例如:count(*) OVER (PARTITION BY x ORDER BY y)。「*」通常不會用於專門的窗函數上,專門的窗函數不允許參數裡有用到 DISTINCT 或 ORDER BY 的語法。
窗函數呼叫只限於 SELECT 回傳列表,及 ORDER BY 子句中。
型別轉換指定從一種資料型別轉換為另一種資料型別。PostgreSQL 接受兩種用於型別轉換的等效語法:
CAST 語法符合 SQL 標準;帶「::」的語法是 PostgreSQL 既有的用法。
如果對於值表示式必須產生的型別沒有歧義(例如,當它被分配給資料表欄位),通常可以省略顯式的型別轉換;系統將在這種情況下自動套用型別轉換。但是,只有在系統目錄中標記為「可以隱式套用」的強制轉換才會執行自動強制轉換。其他強制轉換必須使用顯式強制轉換語法來使用。此限制旨在防止系統默默地套用令人意外的轉換。
也可以使用函數式語法來指定型別轉換:
但是,這僅適用於名稱也可以作為函數名稱使用的型別。例如,雙精度不能用這種方式,但等價的 float8 可以。而且,由於語法衝突,名稱間隔,時間和時間戳記只能使用雙引號才能用於這種方式。因此,使用類似功能的轉換語法會導致不一致,因此可能應該避免。
COLLATE 子句用於覆蓋排序規則的表示式。它附加到所套用的表示式上:
排序規則是一種可以綱要限定識別指標。COLLATE 子句比運算子更緊密;必要時可以使用括號。
如果沒有明確指定排序規則,那麼資料庫系統會從表示式中涉及的欄位中衍生一個排序規則,或者如果表示式中未包含任何欄位,則預設為資料庫的預設排序規則。
COLLATE 子句的兩個常見用法是重寫 ORDER BY 子句中的排序順序,例如:
並覆蓋具有語言環境特性結果的函數或運算子呼叫的排序規則,例如:
但是這會有錯:
因為它試圖將排序規則應用於「>」運算子的結果,該運算符是不可排序的布林資料型別。
例如,以下是每個州中最大的城市人口數量:
陣列建構函數是一種使用其成員元素的值建構陣列的表示式。一個簡單的陣列建構函數由關鍵字 ARRAY,左方括號 [,陣列元素值的表示式列表(用逗號分隔),最後一個右方括號 ] 組成。例如:
可以透過巢狀的陣列建構函數來建構多維陣列。在內部的建構函數中,關鍵字 ARRAY 可以省略。例如,這些語法會產生相同的結果:
由於多維陣列必須是矩形,因此同一級別的內部建構函數必須産生具有相同維數的子陣列。套用於外部 ARRAY 建構函數的任何強制型別都會自動轉送給所有內部建構函數。
多維陣列建構函數的元素可以是任何產生適當型別陣列的東西,不僅只是一個子 ARRAY 結構。例如:
你可以建構一個空陣列,但由於不可能有一個沒有型別的陣列,所以你必須明確地將你的空陣列轉換為所需的型別。例如:
也可以從子查詢的結果中建構一個陣列。在這種形式下,陣列建構函數使用關鍵字 ARRAY 和小括號(不是中括號)的子查詢寫入。例如:
子查詢必須回傳一個資料列。如果子查詢的輸出欄位是非陣列型別,則産生的一維陣列將具有子查詢結果中每個資料列的元素,其元素型別與子查詢的輸出欄位匹配。如果子查詢的輸出欄位是一個陣列型別,則結果將是一個相同型別的陣列,但會是一個更高的維度;在這種情況下,所有子查詢資料列都必須産生具有相同維度的陣列,否則結果將不是矩形。
資料列建構函數是一個表示式,它使用其成員字串的值建構資料列內容(也稱為複合值)。資料建構函數由關鍵字 ROW,左括號,資料列字串的零個或多個表示式(以逗號分隔)所組成,最後則是右括號。例如:
當列表中有多個表示式時,關鍵詞 ROW 是選用的。
在 PostgreSQL 8.2 之前,. 語法在資料列建構函數中不會展開,因此寫了ROW(t., 42) 會建立一個兩個字串欄位的資料列,其第一個是欄位是另一個資料列值。新的建構行為通常更有用。如果您需要嵌套資料列值的舊行為,請不要使用 .* 的內部資料列值,例如 ROW(t, 42)。
預設情況下,由 ROW 表示式建立的值是匿名記錄型別。如有必要,可將其轉換為指定的複合型別 - 資料表的資料列型別或使用 CREATE TYPE AS 建立的複合型別。可能需要明確表示以避免歧義。例如:
資料列建構函數可用於建構要儲存在複合型別資料表欄位中的複合內容,或者要傳遞給接受複合參數的函數。此外,可以比較兩個資料列值或用 IS NULL 或 IS NOT NULL 來測試資料列,例如:
並沒有定義子表示式的運算順序。特別是,運算子或函數的輸入不一定是從左到右或以任何其他固定順序進行運算。
進一步來說,如果一個表示式的結果可以透過只運算它的某些部分來得到,那麼其他子表示式可能根本就不會被運算。 例如,如果有人寫了:
那麼 somefunc() 將(可能)根本不會被呼叫。如果有人寫了:
請注意,這與在某些程語言中發現的布林運算是從左到右的「短路」不同。
因此,將具有副作用的函數用作複雜表示式的一部分是不明智的。在 WHERE 和 HAVING 子句中依賴副作用或運算順序是特別危險的,因為這些子句作為製定執行計劃的一部分經常式會被重新運算。這些子句中的布林表示式(AND / OR / NOT 組合)可以按照布林代數法則的任何方式重新組織。
但這樣是安全的:
以這種方式使用的 CASE 構造將放棄最佳化嘗試,因此只能在必要時進行。(在這個特定的例子中,透過改寫為 y> 1.5 * x 來避免這個問題會更好。)
由於查詢規劃試圖簡化常數子表示式,因此即使資料表中的每一個資料列都具有 x> 0,以至於在執行時永遠不會走到 ELSE,也可能導致除以零的例外情況。
雖然這個特殊的例子看起來很愚蠢,但是在函數中執行的查詢中可能會出現不明顯涉及常數的情況,因為函數參數和局部變數的值可以作為常數插入到查詢中以用於查詢規劃。例如,在 PL/pgSQL 函數中,使用 IF-THEN-ELSE 語句來保護有風險的運算要比將它嵌套在 CASE 表示式中要安全得多。
同一種類型的另一個限制是,CASE 無法阻止運算其中包含的彙總表示式,因為需要在 SELECT 資料列表或 HAVING 子句中的其他表示式之前計算彙總表示式。例如,下面的查詢可能會導致一個除以零例外情況,儘管似乎已經受到保護:
min() 和 avg() 彙總運算是在所有輸入的資料列上同時計算的,因此如果任何員工的資料等於零,則在有任何測試 min() 結果的機會之前,發生除以零的錯誤。相反,使用 WHERE 或 FILTER 子句來防止有問題的輸入資料列,將可以在彙總函數之前來預防這種情況發生。
This section describes functions and operators for examining and manipulating bit strings, that is values of the typesbit
andbit varying
. Aside from the usual comparison operators, the operators shown incan be used. Bit string operands of&
,|
, and#
must be of equal length. When bit shifting, the original length of the string is preserved, as shown in the examples.
Table 9.13. Bit String Operators
The followingSQL-standard functions work on bit strings as well as character strings:length
,bit_length
,octet_length
,position
,substring
,overlay
.
The following functions work on bit strings as well as binary strings:get_bit
,set_bit
. When working with a bit string, these functions number the first (leftmost) bit of the string as bit 0.
In addition, it is possible to cast integral values to and from typebit
. Some examples:
Note that casting to just“bit”means casting tobit(1)
, and so will deliver only the least significant bit of the integer.
Casting an integer tobit(n)
copies the rightmostn
bits. Casting an integer to a bit string width wider than the integer itself will sign-extend on the left.
本節介紹用於檢查和操作字串值的函數和運算子。此節中的字串包括 character,character varying 和 text 的內容。除非另有說明,否則下面列出的所有函數都適用於所有這些型別,但在使用字串型別時要小心自動填充字元的潛在影響。對於 bit-string 型別,一些函數也可以處理。
SQL 定義了一些字串函數,它們使用關鍵字而不是逗號來分隔參數。詳情見 。PostgreSQL 還提供了一般函數呼叫語法的這些函數的版本(參見 )。
注意 在 PostgreSQL 8.3 之前,由於存在從這些資料型別到文字的強制轉換,這些函數也會默默地接受幾個非字串資料型別的值。但這些強制措施已被刪除,因為它們經常引起令人驚訝的行為。不過,字串連接運算子(||)仍然接受非字串輸入,只要至少有一個輸入是字串型別,如 Table 9.8 所示。對於其他情況,如果需要複製先前的行為,請在語法中加入明確的轉換。
format
函數格式化輸出根據格式字串的輸出,其格式類似於 C 函數 sprintf。
formatstr 是一個格式字串,指定如何格式化結果。格式字串中的文字將直接複製到結果中,除非使用格式標示符。格式標示符充當字串中的佔位符,定義後續函數參數應如何格式化並插入結果中。每個 formatarg 參數根據其資料型別的一般輸出規則轉換為文字,然後根據格式標示符進行格式化並插入到結果字串中。
格式標示符由 % 字元引入並具有其語法
組件段落的位置:position(選擇性)
形式為 n$ 的字串,其中 n 是要輸入參數的索引。索引 1 表示 formatstr 之後的第一個參數。如果省略該位置,則預設使用 sequence.flags 中的下一個參數(選擇性)
控制格式標示符輸出格式的其他選項。目前唯一支援的標示是減號( - ),這將使格式標示符的輸出向左對齊。除非還指定了 width,否則這沒有效果。(選擇性)
指定用於顯示格式標示符輸出的最小字元數。輸出在左側或右側(取決於 - 標示)填充,並根據需要填充空格以填充寬度。寬度太小不會導致截斷輸出,但會被忽略。可以使用以下任何一種來指定寬度:正整數;星號()使用下一個函數參數作為寬度;或者 n$ 形式的字串,以使用第 n 個函數參數作為寬度。
如果寬度來自函數參數,則該參數在用於格式標示符值的參數之前使用。如果 width 參數為負,則結果在長度為 abs(width).type(必要)的段落內保持對齊(就像指定了 - 標誌一樣)。
用於産生格式標示符輸出的格式轉換型別。支援以下型別:
s
將參數值格式化為簡單字串。空值被視為空字串。
I
將參數值視為 SQL 標示符,必要時對其進行雙引號。值為 null(相當於 quote_ident)是一個錯誤。
L
引用參數值作為 SQL 文字。空值顯示為字串 NULL,不帶引號(相當於 quote_nullable)。
除了上面描述的格式標示符之外,特殊序列 %% 可用於輸出文字 % 字元。
以下是基本格式轉換的一些範例:
以下是使用寬度欄位和 - 標示的範例:
這些範例顯示了 position 欄位的使用:
與標準 C 函數 sprintf 不同,PostgreSQL 的格式函數允許將具有和不具有位置欄位的格式標示符混合在相同的格式字串中。沒有位置欄位的格式標示符始終使用最後一個參數消耗後的下一個參數。此外,format 函數不要求在格式字串中使用所有函數參數。例如:
The usual comparison operators are available, as shown in.
Table 9.1. Comparison Operators
The!=
operator is converted to<>
in the parser stage. It is not possible to implement!=
and<>
operators that do different things.
Comparison operators are available for all relevant data types. All comparison operators are binary operators that return values of typeboolean
; expressions like1 < 2 < 3
are not valid (because there is no<
operator to compare a Boolean value with3
).
There are also some comparison predicates, as shown in. These behave much like operators, but have special syntax mandated by the SQL standard.
Table 9.2. Comparison Predicates
TheBETWEEN
predicate simplifies range tests:
is equivalent to
Notice thatBETWEEN
treats the endpoint values as included in the range.NOT BETWEEN
does the opposite comparison:
is equivalent to
BETWEEN SYMMETRIC
is likeBETWEEN
except there is no requirement that the argument to the left ofAND
be less than or equal to the argument on the right. If it is not, those two arguments are automatically swapped, so that a nonempty range is always implied.
Ordinary comparison operators yield null (signifying“unknown”), not true or false, when either input is null. For example,7 = NULL
yields null, as does7 <> NULL
. When this behavior is not suitable, use theIS [NOT] DISTINCT FROM
predicates:
For non-null inputs,IS DISTINCT FROM
is the same as the<>
operator. However, if both inputs are null it returns false, and if only one input is null it returns true. Similarly,IS NOT DISTINCT FROM
is identical to=
for non-null inputs, but it returns true when both inputs are null, and false when only one input is null. Thus, these predicates effectively act as though null were a normal data value, rather than“unknown”.
To check whether a value is or is not null, use the predicates:
or the equivalent, but nonstandard, predicates:
Donot_writeexpression
_= NULLbecauseNULL
is not“equal to”NULL
. (The null value represents an unknown value, and it is not known whether two unknown values are equal.)
If theexpression
_is row-valued, thenIS NULL
is true when the row expression itself is null or when all the row's fields are null, whileIS NOT NULL
is true when the row expression itself is non-null and all the row's fields are non-null. Because of this behavior,IS NULL
andIS NOT NULL
do not always return inverse results for row-valued expressions; in particular, a row-valued expression that contains both null and non-null fields will return false for both tests. In some cases, it may be preferable to writerowIS DISTINCT FROM NULL
orrow
_IS NOT DISTINCT FROM NULL
, which will simply check whether the overall row value is null without any additional tests on the row fields.
Boolean values can also be tested using the predicates
These will always return true or false, never a null value, even when the operand is null. A null input is treated as the logical value“unknown”. Notice thatIS UNKNOWN
andIS NOT UNKNOWN
are effectively the same asIS NULL
andIS NOT NULL
, respectively, except that the input expression must be of Boolean type.
Table 9.3. Comparison Functions
For enum types (described in), there are several functions that allow cleaner programming without hard-coding particular values of an enum type. These are listed in. The examples assume an enum type created as:
Table 9.32. Enum Support Functions
Notice that except for the two-argument form ofenum_range
, these functions disregard the specific value passed to them; they care only about its declared data type. Either null or a specific value of the type can be passed, with the same result. It is more common to apply these functions to a table column or function argument than to a hardwired type name as suggested by the examples.
ThePostgreSQLformatting functions provide a powerful set of tools for converting various data types (date/time, integer, floating point, numeric) to formatted strings and for converting from formatted strings to specific data types.lists them. These functions all follow a common calling convention: the first argument is the value to be formatted and the second argument is a template that defines the output or input format.
Table 9.23. Formatting Functions
There is also a single-argumentto_timestamp
function; see.
to_timestamp
andto_date
exist to handle input formats that cannot be converted by simple casting. For most standard date/time formats, simply casting the source string to the required data type works, and is much easier. Similarly,to_number
is unnecessary for standard numeric representations.
In ato_char
output template string, there are certain patterns that are recognized and replaced with appropriately-formatted data based on the given value. Any text that is not a template pattern is simply copied verbatim. Similarly, in an input template string (for the other functions), template patterns identify the values to be supplied by the input data string.
shows the template patterns available for formatting date and time values.
Table 9.24. Template Patterns for Date/Time Formatting
Table 9.25. Template Pattern Modifiers for Date/Time Formatting
Usage notes for date/time formatting:
FM
suppresses leading zeroes and trailing blanks that would otherwise be added to make the output of a pattern be fixed-width. InPostgreSQL,FM
modifies only the next specification, while in OracleFM
affects all subsequent specifications, and repeatedFM
modifiers toggle fill mode on and off.
TM
does not include trailing blanks.to_timestamp
andto_date
ignore theTM
modifier.
to_timestamp
andto_date
skip multiple blank spaces in the input string unless theFX
option is used. For example,to_timestamp('2000 JUN', 'YYYY MON')
works, butto_timestamp('2000 JUN', 'FXYYYY MON')
returns an error becauseto_timestamp
expects one space only.FX
must be specified as the first item in the template.
Ordinary text is allowed into_char
templates and will be output literally. You can put a substring in double quotes to force it to be interpreted as literal text even if it contains pattern key words. For example, in'"Hello Year "YYYY'
, theYYYY
will be replaced by the year data, but the singleY
inYear
will not be. Into_date
,to_number
, andto_timestamp
, double-quoted strings skip the number of input characters contained in the string, e.g."XX"
skips two input characters.
If you want to have a double quote in the output you must precede it with a backslash, for example'\"YYYY Month\"'
.
Into_timestamp
andto_date
, if the year format specification is less than four digits, e.g.YYY
, and the supplied year is less than four digits, the year will be adjusted to be nearest to the year 2020, e.g.95
becomes 1995.
Into_timestamp
andto_date
, theYYYY
conversion has a restriction when processing years with more than 4 digits. You must use some non-digit character or template afterYYYY
, otherwise the year is always interpreted as 4 digits. For example (with the year 20000):to_date('200001131', 'YYYYMMDD')
will be interpreted as a 4-digit year; instead use a non-digit separator after the year, liketo_date('20000-1131', 'YYYY-MMDD')
orto_date('20000Nov31', 'YYYYMonDD')
.
Into_timestamp
andto_date
, theCC
(century) field is accepted but ignored if there is aYYY
,YYYY
orY,YYY
field. IfCC
is used withYY
orY
then the result is computed as that year in the specified century. If the century is specified but the year is not, the first year of the century is assumed.
Into_timestamp
andto_date
, weekday names or numbers (DAY
,D
, and related field types) are accepted but are ignored for purposes of computing the result. The same is true for quarter (Q
) fields.
Into_timestamp
andto_date
, an ISO 8601 week-numbering date (as distinct from a Gregorian date) can be specified in one of two ways:
Year, week number, and weekday: for exampleto_date('2006-42-4', 'IYYY-IW-ID')
returns the date2006-10-19
. If you omit the weekday it is assumed to be 1 (Monday).
Year and day of year: for exampleto_date('2006-291', 'IYYY-IDDD')
also returns2006-10-19
.
Attempting to enter a date using a mixture of ISO 8601 week-numbering fields and Gregorian date fields is nonsensical, and will cause an error. In the context of an ISO 8601 week-numbering year, the concept of a“month”or“day of month”has no meaning. In the context of a Gregorian year, the ISO week has no meaning.
Caution
Into_timestamp
, millisecond (MS
) or microsecond (US
) fields are used as the seconds digits after the decimal point. For exampleto_timestamp('12.3', 'SS.MS')
is not 3 milliseconds, but 300, because the conversion treats it as 12 + 0.3 seconds. So, for the formatSS.MS
, the input values12.3
,12.30
, and12.300
specify the same number of milliseconds. To get three milliseconds, one must write12.003
, which the conversion treats as 12 + 0.003 = 12.003 seconds.
Here is a more complex example:to_timestamp('15:12:02.020.001230', 'HH24:MI:SS.MS.US')
is 15 hours, 12 minutes, and 2 seconds + 20 milliseconds + 1230 microseconds = 2.021230 seconds.
to_char(..., 'ID')
's day of the week numbering matches theextract(isodow from ...)
function, butto_char(..., 'D')
's does not matchextract(dow from ...)
's day numbering.
to_char(interval)
formatsHH
andHH12
as shown on a 12-hour clock, for example zero hours and 36 hours both output as12
, whileHH24
outputs the full hour value, which can exceed 23 in aninterval
value.
Table 9.26. Template Patterns for Numeric Formatting
Usage notes for numeric formatting:
A sign formatted usingSG
,PL
, orMI
is not anchored to the number; for example,to_char(-12, 'MI9999')
produces'- 12'
butto_char(-12, 'S9999')
produces' -12'
. The Oracle implementation does not allow the use ofMI
before9
, but rather requires that9
precedeMI
.
9
results in a value with the same number of digits as there are9
s. If a digit is not available it outputs a space.
TH
does not convert values less than zero and does not convert fractional numbers.
PL
,SG
, andTH
arePostgreSQLextensions.
V
withto_char
multiplies the input values by10^n
, where_n
_is the number of digits followingV
.V
withto_number
divides in a similar manner.to_char
andto_number
do not support the use ofV
combined with a decimal point (e.g.,99.9V99
is not allowed).
EEEE
(scientific notation) cannot be used in combination with any of the other formatting patterns or modifiers other than digit and decimal point patterns, and must be at the end of the format string (e.g.,9.99EEEE
is a valid pattern).
Table 9.27. Template Pattern Modifiers for Numeric Formatting
Table 9.28. to_char
Examples
Mathematical operators are provided for manyPostgreSQLtypes. For types without standard mathematical conventions (e.g., date/time types) we describe the actual behavior in subsequent sections.
shows the available mathematical operators.
Table 9.4. Mathematical Operators
Table 9.5. Mathematical Functions
Table 9.6. Random Functions
Table 9.7. Trigonometric Functions
Another way to work with angles measured in degrees is to use the unit transformation functionsradians()
anddegrees()
shown earlier. However, using the degree-based trigonometric functions is preferred, as that way avoids roundoff error for special cases such assind(30)
.
This section describes functions and operators for examining and manipulating values of typebytea
.
SQLdefines some string functions that use key words, rather than commas, to separate arguments. Details are in.PostgreSQLalso provides versions of these functions that use the regular function invocation syntax (see).
The sample results shown on this page assume that the server parameteris set toescape
(the traditional PostgreSQL format).
Table 9.11. SQLBinary String Functions and Operators
Additional binary string manipulation functions are available and are listed in. Some of them are used internally to implement theSQL-standard string functions listed in.
Table 9.12. Other Binary String Functions
get_byte
andset_byte
number the first byte of a binary string as byte 0.get_bit
andset_bit
number bits from the right within each byte; for example bit 0 is the least significant bit of the first byte, and bit 15 is the most significant bit of the second byte.
shows the operators available for thecidr
andinet
types. The operators<<
,<<=
,>>
,>>=
, and&&
test for subnet inclusion. They consider only the network parts of the two addresses (ignoring any host part) and determine whether one network is identical to or a subnet of the other.
Table 9.36. cidr
andinet
Operators
Table 9.37. cidr
andinet
Functions
Anycidr
value can be cast toinet
implicitly or explicitly; therefore, the functions shown above as operating oninet
also work oncidr
values. (Where there are separate functions forinet
andcidr
, it is because the behavior should be different for the two cases.) Also, it is permitted to cast aninet
value tocidr
. When this is done, any bits to the right of the netmask are silently zeroed to create a validcidr
value. In addition, you can cast a text value toinet
orcidr
using normal casting syntax: for example,inet(expression
)orcolname
::cidr.
Table 9.38. macaddr
Functions
Themacaddr
type also supports the standard relational operators (>
,<=
, etc.) for lexicographical ordering, and the bitwise arithmetic operators (~
,&
and|
) for NOT, AND and OR.
Table 9.39. macaddr8
Functions
Themacaddr8
type also supports the standard relational operators (>
,<=
, etc.) for ordering, and the bitwise arithmetic operators (~
,&
and|
) for NOT, AND and OR.
Table 9-28 shows the available functions for date/time value processing, with details appearing in the following subsections. Table 9-27 illustrates the behaviors of the basic arithmetic operators (+, *, etc.). For formatting functions, refer to . You should be familiar with the background information on date/time data types from .
All the functions and operators described below that take time or timestamp inputs actually come in two variants: one that takes time with time zone or timestamp with time zone, and one that takes time without time zone or timestamp without time zone. For brevity, these variants are not shown separately. Also, the + and * operators come in commutative pairs (for example both date + integer and integer + date); we show only one of each such pair.
Table 9-27. Date/Time Operators
Table 9-28. Date/Time Functions
In addition to these functions, the SQL OVERLAPS operator is supported:
This expression yields true when two time periods (defined by their endpoints) overlap, false when they do not overlap. The endpoints can be specified as pairs of dates, times, or time stamps; or as a date, time, or time stamp followed by an interval. When a pair of values is provided, either the start or the end can be written first; OVERLAPS automatically takes the earlier value of the pair as the start. Each time period is considered to represent the half-open interval start <= time < end, unless start and end are equal in which case it represents that single time instant. This means for instance that two time periods with only an endpoint in common do not overlap.
When adding an interval value to (or subtracting an interval value from) a timestamp with time zone value, the days component advances or decrements the date of the timestamp with time zone by the indicated number of days. Across daylight saving time changes (when the session time zone is set to a time zone that recognizes DST), this means interval '1 day' does not necessarily equal interval '24 hours'. For example, with the session time zone set to CST7CDT, timestamp with time zone '2005-04-02 12:00-07' + interval '1 day' will produce timestamp with time zone '2005-04-03 12:00-06', while adding interval '24 hours' to the same initial timestamp with time zone produces timestamp with time zone '2005-04-03 13:00-06', as there is a change in daylight saving time at 2005-04-03 02:00 in time zone CST7CDT.
Note there can be ambiguity in the months field returned by age
because different months have different numbers of days. PostgreSQL's approach uses the month from the earlier of the two dates when calculating partial months. For example, age('2004-06-01', '2004-04-30') uses April to yield 1 mon 1 day, while using May would yield 1 mon 2 days because May has 31 days, while April has only 30.
Subtraction of dates and timestamps can also be complex. One conceptually simple way to perform subtraction is to convert each value to a number of seconds using EXTRACT(EPOCH FROM ...), then subtract the results; this produces the number of seconds between the two values. This will adjust for the number of days in each month, timezone changes, and daylight saving time adjustments. Subtraction of date or timestamp values with the "-" operator returns the number of days (24-hours) and hours/minutes/seconds between the values, making the same adjustments. The age
function returns years, months, days, and hours/minutes/seconds, performing field-by-field subtraction and then adjusting for negative field values. The following queries illustrate the differences in these approaches. The sample results were produced with timezone = 'US/Eastern'; there is a daylight saving time change between the two dates used:
EXTRACT
, date_part
The extract
function retrieves subfields such as year or hour from date/time values. source must be a value expression of type timestamp, time, or interval. (Expressions of type dateare cast to timestamp and can therefore be used as well.) field is an identifier or string that selects what field to extract from the source value. The extract
function returns values of type double precision. The following are valid field names:century
The century
The first century starts at 0001-01-01 00:00:00 AD, although they did not know it at the time. This definition applies to all Gregorian calendar countries. There is no century number 0, you go from -1 century to 1 century. If you disagree with this, please write your complaint to: Pope, Cathedral Saint-Peter of Roma, Vatican.day
For timestamp values, the day (of the month) field (1 - 31) ; for interval values, the number of days
decade
The year field divided by 10
dow
The day of the week as Sunday (0) to Saturday (6)
Note that extract
's day of the week numbering differs from that of the to_char(..., 'D')
function.doy
The day of the year (1 - 365/366)
epoch
For timestamp with time zone values, the number of seconds since 1970-01-01 00:00:00 UTC (can be negative); for date and timestamp values, the number of seconds since 1970-01-01 00:00:00 local time; for interval values, the total number of seconds in the interval
Here is how you can convert an epoch value back to a time stamp:
(The to_timestamp
function encapsulates the above conversion.)hour
The hour field (0 - 23)
isodow
The day of the week as Monday (1) to Sunday (7)
This is identical to dow except for Sunday. This matches the ISO 8601 day of the week numbering.isoyear
The ISO 8601 week-numbering year that the date falls in (not applicable to intervals)
Each ISO 8601 week-numbering year begins with the Monday of the week containing the 4th of January, so in early January or late December the ISO year may be different from the Gregorian year. See the week field for more information.
This field is not available in PostgreSQL releases prior to 8.3.microseconds
The seconds field, including fractional parts, multiplied by 1 000 000; note that this includes full seconds
millennium
The millennium
Years in the 1900s are in the second millennium. The third millennium started January 1, 2001.milliseconds
The seconds field, including fractional parts, multiplied by 1000. Note that this includes full seconds.
minute
The minutes field (0 - 59)
month
For timestamp values, the number of the month within the year (1 - 12) ; for interval values, the number of months, modulo 12 (0 - 11)
quarter
The quarter of the year (1 - 4) that the date is in
second
timezone
The time zone offset from UTC, measured in seconds. Positive values correspond to time zones east of UTC, negative values to zones west of UTC. (Technically, PostgreSQL uses UT1 because leap seconds are not handled.)timezone_hour
The hour component of the time zone offsettimezone_minute
The minute component of the time zone offsetweek
The number of the ISO 8601 week-numbering week of the year. By definition, ISO weeks start on Mondays and the first week of a year contains January 4 of that year. In other words, the first Thursday of a year is in week 1 of that year.
In the ISO week-numbering system, it is possible for early-January dates to be part of the 52nd or 53rd week of the previous year, and for late-December dates to be part of the first week of the next year. For example, 2005-01-01 is part of the 53rd week of year 2004, and 2006-01-01 is part of the 52nd week of year 2005, while 2012-12-31 is part of the first week of 2013. It's recommended to use the isoyear field together with week to get consistent results.
year
The year field. Keep in mind there is no 0 AD, so subtracting BC years from AD years should be done with care.
The date_part
function is modeled on the traditional Ingres equivalent to the SQL-standard function extract
:
Note that here the field parameter needs to be a string value, not a name. The valid field names for date_part
are the same as for extract
.
date_trunc
The function date_trunc
is conceptually similar to the trunc
function for numbers.
source is a value expression of type timestamp or interval. (Values of type date and time are cast automatically to timestamp or interval, respectively.) field selects to which precision to truncate the input value. The return value is of type timestamp or interval with all fields that are less significant than the selected one set to zero (or one, for day and month).
Valid values for field are:
Examples:
Table 9-29. AT TIME ZONE Variants
Examples (assuming the local time zone is PST8PDT):
The first example takes a time stamp without time zone and interprets it as MST time (UTC-7), which is then converted to PST (UTC-8) for display. The second example takes a time stamp specified in EST (UTC-5) and converts it to local time in MST (UTC-7).
The function timezone
(zone, timestamp) is equivalent to the SQL-conforming construct timestamp AT TIME ZONE zone.
PostgreSQL provides a number of functions that return values related to the current date and time. These SQL-standard functions all return values based on the start time of the current transaction:
CURRENT_TIME
and CURRENT_TIMESTAMP
deliver values with time zone; LOCALTIME
and LOCALTIMESTAMP
deliver values without time zone.
CURRENT_TIME
, CURRENT_TIMESTAMP
, LOCALTIME
, and LOCALTIMESTAMP
can optionally take a precision parameter, which causes the result to be rounded to that many fractional digits in the seconds field. Without a precision parameter, the result is given to the full available precision.
Some examples:
Since these functions return the start time of the current transaction, their values do not change during the transaction. This is considered a feature: the intent is to allow a single transaction to have a consistent notion of the "current" time, so that multiple modifications within the same transaction bear the same time stamp.
Note: Other database systems might advance these values more frequently.
PostgreSQL also provides functions that return the start time of the current statement, as well as the actual current time at the instant the function is called. The complete list of non-SQL-standard time functions is:
transaction_timestamp()
is equivalent to CURRENT_TIMESTAMP
, but is named to clearly reflect what it returns. statement_timestamp()
returns the start time of the current statement (more specifically, the time of receipt of the latest command message from the client). statement_timestamp()
and transaction_timestamp()
return the same value during the first command of a transaction, but might differ during subsequent commands. clock_timestamp()
returns the actual current time, and therefore its value changes even within a single SQL command. timeofday()
is a historical PostgreSQL function. Like clock_timestamp()
, it returns the actual current time, but as a formatted text string rather than a timestamp with time zone value. now()
is a traditional PostgreSQL equivalent to transaction_timestamp()
.
All the date/time data types also accept the special literal value now to specify the current date and time (again, interpreted as the transaction start time). Thus, the following three all return the same result:
Tip: You do not want to use the third form when specifying a DEFAULT clause while creating a table. The system will convert now to a timestamp as soon as the constant is parsed, so that when the default value is needed, the time of the table creation would be used! The first two forms will not be evaluated until the default value is used, because they are function calls. Thus they will give the desired behavior of defaulting to the time of row insertion.
The following functions are available to delay execution of the server process:
pg_sleep
makes the current session's process sleep until seconds seconds have elapsed. seconds is a value of type double precision, so fractional-second delays can be specified. pg_sleep_for
is a convenience function for larger sleep times specified as an interval. pg_sleep_until
is a convenience function for when a specific wake-up time is desired. For example:
Note: The effective resolution of the sleep interval is platform-specific; 0.01 seconds is a common value. The sleep delay will be at least as long as specified. It might be longer depending on factors such as server load. In particular,
pg_sleep_until
is not guaranteed to wake up exactly at the specified time, but it will not wake up any earlier.
The geometric typespoint
,box
,lseg
,line
,path
,polygon
, andcircle
have a large set of native support functions and operators, shown in,, and.
Note that the“same as”operator,~=
, represents the usual notion of equality for thepoint
,box
,polygon
, andcircle
types. Some of these types also have an=
operator, but=
compares for equal_areas_only. The other scalar comparison operators (<=
and so on) likewise compare areas for these types.
Table 9.33. Geometric Operators
BeforePostgreSQL8.2, the containment operators@>
and<@
were respectively called~
and@
. These names are still available, but are deprecated and will eventually be removed.
Table 9.34. Geometric Functions
Table 9.35. Geometric Type Conversion Functions
It is possible to access the two component numbers of apoint
as though the point were an array with indexes 0 and 1. For example, ift.p
is apoint
column thenSELECT p[0] FROM t
retrieves the X coordinate andUPDATE t SET p[1] = ...
changes the Y coordinate. In the same way, a value of typebox
orlseg
can be treated as an array of twopoint
values.
Thearea
function works for the typesbox
,circle
, andpath
. Thearea
function only works on thepath
data type if the points in thepath
are non-intersecting. For example, thepath'((0,0),(0,1),(2,1),(2,2),(1,2),(1,0),(0,0))'::PATH
will not work; however, the following visually identicalpath'((0,0),(0,1),(1,1),(1,2),(2,2),(2,1),(1,1),(1,0),(0,0))'::PATH
will work. If the concept of an intersecting versus non-intersectingpath
is confusing, draw both of the abovepath
s side by side on a piece of graph paper.
Indicates that a function accepts any data type (see).
Indicates that a function accepts any array data type (see).
Indicates that a function accepts any non-array data type (see).
Indicates that a function accepts any enum data type (seeand).
Indicates that a function accepts any range data type (seeand).
除了這個列表之外,還有一些建構式也會應用到表示式,但並沒有特別定義語法規則。一般來說,他們會包含函數或運算子的操作,在中會有適當的說明。其中有一個例子便是 IS NULL 字句。
我們已經在 中討論過常數了,所以接下來就從常數以下的項目繼續說明。
「correlation」(所屬名稱)是其所屬表格的名稱(也可能需要包含結構名),或是表格的別名(在 FROM 子句中所定義的)。所屬名稱和分隔用的句點是可以省略的,如果欄位名稱在目前查詢中的所有表格中是唯一的話。()
在最後一個例子中,括號是必須的。關於陣列,在 有更多說明。
這個記號在不同的地方有不同的用法,請參閱 的說明。
運算子記號的語法規則依 的說明,或是關鍵字 AND、OR、和 NOT,又或是如下形式的限定運算子名稱:
哪些特定的運算子的使用與運算方式,端看系統與使用者如何定義。在中會說明內建的運算子詳情。
內建函數在說明,其他的函數可由使用者自訂。
參數可以是選擇性的附加名稱,請參閱 的內容。
函數如果只有一個參數,而又是複合型別的話,就稱作使用了欄位選擇語法;反過來說,欄位選擇語法也可以寫成函數的形式。這是因為 col(table) 和 table.col 是可以互換的。這並非標準 SQL,但 PostgreSQL 支援了,因為這使得函數的使用可以模擬「計算欄位」(computed fields)。更多資訊請參閱 。
預先內建的彙總函數將在 中介紹,其他彙總函數可以由使用者自行設計。
當彙總表示式使用在子查詢(參閱 及 )中時,彙總計算就會一般性地處理子查詢中的資料。但如果該彙總計算的參數用到了外層的變數時,就會產生例外情況:彙整計算是屬於最接近的外層查詢,並且只處理該層的查詢資料。這個彙總表示式對整體而言,只是一個子查詢的引用,它會被視為一個常數的結果,限制它只會出現在 HAVING 子句的運算層次而已。
window_name 是一個定義在 WINDOW 子句中的命名。另一方面,一個完整的窗也可以是被括號括起來,使用和 WINDOW 子句相同語法的定義。詳見 頁面。值得探討的是,OVER wname 並不完全等同於 OVER (wname ...);後者隱含著複製及修改窗的定義,而如果包含 frame 子句的話,就會被拒絕執行。
內建的窗函數會在 中說明,使用者也可以自行設計窗函數。任何內建或自訂的一般函數或統計函數,都可以當作窗函數來使用。(有序集合和假定集合的彙總數,目前不能當作窗函數來使用。)
更多窗函數的說明請參閱 、、及 。
當強制轉換應用於已知型別的值表示式時,它表示執行時型別轉換。只有定義了合適的型別轉換操作,操作才能成功。請注意,這與使用帶常數的強制轉換略有不同,如 所示。應用於未經修飾的字串文字的強制轉換表示將型別初始分配給文字常數,因此對於任何型別(如果字串文字的內容都是資料型別的可接受輸入語法)都會成功。
函數式語法實際上只是一個函數呼叫。當兩個標準轉換語法之一用於執行轉換時,它將在內部呼叫已註冊的函數來執行轉換。按照慣例,這些轉換函數與它們的輸出類型具有相同的名稱,因此「函數式語法」只不過是直接呼叫底層的轉換函數。顯然,這不是一個可移植式應用程序應該依賴的東西。有關更多詳情,請參閱 。
請注意,在後者的情況下,COLLATE 子句附加到我們希望影響的運算子的輸入參數。 無論運算子或函數呼叫 COLLATE 子句的哪個參數被附加到哪個參數都沒有關係,因為運算子或函數套用的排序規則是透過考慮所有參數衍生的,並且顯式 COLLATE 子句將覆蓋所有其他排序規則參數。(然而,將不匹配的 COLLATE 子句連接到多個參數是錯誤的,更多細節請參閱)。因此,這會産生與前面的例子相同的結果:
Scalar 子查詢指的是括號中的普通 SELECT 查詢,但它只回傳一個資料列的一個欄位。(有關撰寫查詢的訊息,請參閱。)執行 SELECT 查詢並在周圍的值表示式中使用單個回傳的值。使用回傳多於一個資料列或多於一個欄位的查詢作為 scalar 子查詢是錯誤的。(但是,如果在特定執行過程中子查詢不回傳任何資料列,則不會出現錯誤;Scalar 結果將視為空)。子查詢可以引用周圍查詢中的變數,該變數在任何一次運算期間都將用作常數的子查詢。有關子查詢的其他表示式,另請參閱。
預設情況下,陣列元素型別是成員表示式的通用型別,使用與 UNION 或 CASE 結構相同的規則來決定(參閱 )。您也可以透過明確將陣列建構函數轉換為所需的型別來覆蓋它,例如:
這與分別將每個表示式轉換為陣列元素型別的效果相同。有關型別轉換的更多訊息,請參閱。
用 ARRAY 建構的陣列索引值的下標始終以 1 開頭。有關陣列的更多訊息,請參閱。
資料列建構函數可以包含語法 rowvalue.,它將被延展為資料列內容的元素列表,就像在 SELECT 回傳列表的使用 . 語法時一樣(請參閱)。例如,如果資料列具有欄位 f1 和 f2,則這些欄位是相同的:
更多細節請參閱。資料列建構函數也可以與子查詢結合使用,如所述。
如果必須強制執行某部份的運算指令,則可以使用 CASE 結構(請參閱)。例如,這是試圖避免在 WHERE 子句中除以零不可信任的方式:
然而,CASE 對於這些問題並不是萬能的。上述技術的一個局限是它不能阻止對常數子表示式的預先評估。如所述,標記為 IMMUTABLE 的函數和運算子可以在查詢計劃時進行運算,而不是在執行時進行運算。因此,例如:
還有其他字串操作函數可用,在 中列出。 其中一些內部用於實作 SQL 標準的字串函數列在 。
concat,concat_ws 和 format 函數是可變參數,因此可以將值連接或格式化成標記為 VARIADIC 關鍵字的陣列(請參閱)。陣列的元素被視為它們是函數的單獨普通參數。如果 variadic 陣列參數為 NULL,則 concat 和 concat_ws 回傳 NULL,但 format 將 NULL 視為零元素陣列。
另請參閱中的彙總函數 string_agg。
%I 和 %L 格式標示符對於安全地建構動態 SQL 語句特別有用。詳見。
Some applications might expect thatexpression
= NULLreturns true if_expression
_evaluates to the null value. It is highly recommended that these applications be modified to comply with the SQL standard. However, if that cannot be done theconfiguration variable is available. If it is enabled,PostgreSQLwill convertx = NULL
clauses tox IS NULL
.
Some comparison-related functions are also available, as shown in.
Modifiers can be applied to any template pattern to alter its behavior. For example,FMMonth
is theMonth
pattern with theFM
modifier.shows the modifier patterns for date/time formatting.
Whileto_date
will reject a mixture of Gregorian and ISO week-numbering date fields,to_char
will not, since output format specifications likeYYYY-MM-DD (IYYY-IDDD)
can be useful. But avoid writing something likeIYYY-MM-DD
; that would yield surprising results near the start of the year. (Seefor more information.)
shows the template patterns available for formatting numeric values.
Certain modifiers can be applied to any template pattern to alter its behavior. For example,FM9999
is the9999
pattern with theFM
modifier.shows the modifier patterns for numeric formatting.
shows some examples of the use of theto_char
function.
The bitwise operators work only on integral data types, whereas the others are available for all numeric data types. The bitwise operators are also available for the bit string typesbit
andbit varying
, as shown in.
shows the available mathematical functions. In the table,dp
indicatesdouble precision
. Many of these functions are provided in multiple forms with different argument types. Except where noted, any given form of a function returns the same data type as its argument. The functions working withdouble precision
data are mostly implemented on top of the host system's C library; accuracy and behavior in boundary cases can therefore vary depending on the host system.
shows functions for generating random numbers.
The characteristics of the values returned byrandom()
depend on the system implementation. It is not suitable for cryptographic applications; seemodule for an alternative.
Finally,shows the available trigonometric functions. All trigonometric functions take arguments and return values of typedouble precision
. Each of the trigonometric functions comes in two variants, one that measures angles in radians and one that measures angles in degrees.
See also the aggregate functionstring_agg
inand the large object functions in.
shows the functions available for use with thecidr
andinet
types. Theabbrev
,host
, andtext
functions are primarily intended to offer alternative display formats.
shows the functions available for use with themacaddr
type. The functiontrunc(macaddr
)returns a MAC address with the last 3 bytes set to zero. This can be used to associate the remaining prefix with a manufacturer.
shows the functions available for use with themacaddr8
type. The functiontrunc(macaddr8
)returns a MAC address with the last 5 bytes set to zero. This can be used to associate the remaining prefix with a manufacturer.
The seconds field, including fractional parts (0 - 59)
The extract
function is primarily intended for computational processing. For formatting date/time values for display, see .
The AT TIME ZONE construct allows conversions of time stamps to different time zones. shows its variants.
In these expressions, the desired time zone zone can be specified either as a text string (e.g., 'PST') or as an interval (e.g., INTERVAL '-08:00'). In the text case, a time zone name can be specified in any of the ways described in .
Function
Return Type
Description
Example
Result
ascii(
string
)
int
參數的第一個字元的 ASCII 碼。對於 UTF8,回傳字元的 Unicode 代碼。對於其他多位元組編碼,參數必須是 ASCII 字元。
ascii('x')
120
btrim(
string
text
[, characters
text
])
text
從字串的開頭和結尾刪除特定字元的最長字串(預設為空格)
btrim('xyxtrimyyx', 'xyz')
trim
chr(int
)
text
輸出給定代碼的字元。對於 UTF8,該參數被視為 Unicode 代碼。對於其他多位元組編碼,參數必須指定 ASCII 字元。不允許使用 NULL(0)字元,因為文字資料型別無法儲存這個位元組。
chr(65)
A
concat(
str
"any"
[, str
"any"
[, ...] ])
text
連接所有參數的文字結果。NULL 參數會被忽略。
concat('abcde', 2, NULL, 22)
abcde222
concat_ws(
sep
text
, str
"any"
[,str
"any"
[, ...] ])
text
使用分隔字元連接除第一個參數以外的所有參數。第一個參數用作分隔字串。NULL 參數會被忽略。
concat_ws(',', 'abcde', 2, NULL, 22)
abcde,2,22
convert(
string
bytea
,src_encoding
name
, dest_encoding
name
)
bytea
將字串轉換為 dest_encoding。原始編碼由 src_encoding 指定。該字串必須在此編碼中有效。可以透過 CREATE CONVERSION 定義轉換。還有一些預定義的轉換。有關可用的轉換,請參閱 Table 9.10。
convert('text_in_utf8', 'UTF8', 'LATIN1')
text_in_utf8
represented in Latin-1 encoding (ISO 8859-1)
convert_from(
string
bytea
,src_encoding
name
)
text
將字串轉換為資料庫編碼。原始編碼由 src_encoding 指定。該字串必須在此編碼中有效。
convert_from('text_in_utf8', 'UTF8')
text_in_utf8
represented in the current database encoding
convert_to(
string
text
,dest_encoding
name
)
bytea
將字串轉換為 dest_encoding。
convert_to('some text', 'UTF8')
some text
represented in the UTF8 encoding
decode(
string
text
, format
text
)
bytea
從字串中的文字表示中解碼二進位資料。格式選項與編碼相同。
decode('MTIzAAE=', 'base64')
\x3132330001
encode(
data
bytea
, format
text
)
text
將二進制資料編碼為文字表示。支援的格式為:base64,hex,escape。escape 將零位元組和 high-bit-set 位元組轉換為八進制序列(\nnn)並將倒斜線加倍。
encode(E'123\\000\\001', 'base64')
MTIzAAE=
format
(formatstr
text
[,formatarg
"any"
[, ...] ])
text
根據格式字串格式化參數。此功能類似於 C 函數 sprintf。詳見 9.4.1 節。
format('Hello %s, %1$s', 'World')
Hello World, World
initcap(
string
)
text
將每個單詞的第一個字母轉換為大寫,其餘單詞轉換為小寫。單詞是由非字母數字字元分隔的字母數字字元序列。
initcap('hi THOMAS')
Hi Thomas
left(
str
text
, n
int
)
text
回傳字串中的前 n 個字元。當 n 為負數時,回傳除最後 |n| 之外的所有內容字元。
left('abcde', 2)
ab
length(
string
)
int
字串中的字元數
length('jose')
4
length(
string
bytea
, encoding
name
)
int
給定編碼中字串中的字元數。該字串必須在此編碼中有效。
length('jose', 'UTF8')
4
lpad(
string
text
, length
int
[,fill
text
])
text
透過在字元填充前加上字串填充(預設為空格)。 如果字串已經長於長度,那麼它將被截斷(在右側)。
lpad('hi', 5, 'xy')
xyxhi
ltrim(
string
text
[, characters
text
])
text
從字串的開頭刪除最長指定字元的字串(預設為空格)
ltrim('zzzytest', 'xyz')
test
md5(
string
)
text
計算字串的 MD5 雜湊值,以十六進位形式回傳結果
md5('abc')
900150983cd24fb0 d6963f7d28e17f72
parse_ident(
qualified_identifier
text
[, strictmode
boolean
DEFAULT true ] )
text[]
將 qualified_identifier 以標示字拆分為陣列,刪除任何單個標示字的引用。預設情況下,最後一個標示字後面的額外字元將被視為錯誤;但如果第二個參數為 false,則忽略這些額外的字元。(此行為對於解析函數等物件的名稱很有用。)請注意,此函數不會截斷超長標示字。如果要截斷,可以將結果轉換為 name[]。
parse_ident('"SomeSchema".someTable')
{SomeSchema,sometable}
pg_client_encoding()
name
目前用戶端的編碼名稱
pg_client_encoding()
SQL_ASCII
quote_ident(
string
text
)
text
回傳適當引用的字串,以用作 SQL 語句字串中的標示字。僅在必要時加上引號(即如果字串包含非標示字或將被大小寫折疊)。 嵌入式引號會正確加倍。請參閱例 42.1。
quote_ident('Foo bar')
"Foo bar"
quote_literal(
string
text
)
text
回傳適當引用的字串,以用作 SQL 語句字串中的字串文字。嵌入式單引號和倒斜線會適當加倍。請注意,quote_literal 在 null 輸入時回傳 null;如果參數可能為 null,則 quote_nullable 通常更合適。請參閱例 42.1。
quote_literal(E'O\'Reilly')
'O''Reilly'
quote_literal(
value
anyelement
)
text
將給定的值強制轉換為文字型別,然後將其引用為文字。嵌入式單引號和反斜線會適當加倍。
quote_literal(42.5)
'42.5'
quote_nullable(
string
text
)
text
回傳適當引用的字串,以用作 SQL 語句字串中的字串文字;或者,如果參數為 null,則回傳NULL。嵌入式單引號和倒斜線將適當加倍。請參閱例 42.1。
quote_nullable(NULL)
NULL
quote_nullable(
value
anyelement
)
text
將給定的值強制轉換為文字型別,然後將其引用為文字;或者,如果參數為 null,則回傳 NULL。嵌入式單引號和倒斜線將適當加倍。
quote_nullable(42.5)
'42.5'
regexp_match(
string
text
,pattern
text
[, flags
text
])
text[]
回傳由 POSIX 正規表示式與字串的第一個匹配產生的子字串。有關更多訊息,請參閱第 9.7.3 節。
regexp_match('foobarbequebaz', '(bar)(beque)')
{bar,beque}
regexp_matches(
string
text
,pattern
text
[, flags
text
])
setof text[]
回傳透過將 POSIX 正規表示式與字串匹配而得到的子字串。有關更多訊息,請參閱第 9.7.3 節。
regexp_matches('foobarbequebaz', 'ba.', 'g')
{bar}{baz}
(2 rows)
regexp_replace(
string
text
,pattern
text
, replacement
text
[, flags
text
])
text
替換與 POSIX 正規表示式匹配的子字串。有關更多訊息,請參閱第 9.7.3 節。
regexp_replace('Thomas', '.[mN]a.', 'M')
ThM
regexp_split_to_array(
string
text
, pattern
text
[, flags
text
])
text[]
使用 POSIX 正規表示式作為分隔字拆分字串。有關更多訊息,請參閱第 9.7.3 節。
regexp_split_to_array('hello world', E'\\s+')
{hello,world}
regexp_split_to_table(
string
text
, pattern
text
[, flags
text
])
setof text
使用 POSIX 正規表示式作為分隔字拆分字串。有關更多訊息,請參閱第 9.7.3 節。
regexp_split_to_table('hello world', E'\\s+')
helloworld
(2 rows)
repeat(
string
text
, number
int
)
text
將字串重複的指定次數
repeat('Pg', 4)
PgPgPgPg
replace(
string
text
, from
text
,to
text
)
text
以子字串 to 替換所有符合 from 的子字串
replace('abcdefabcdef', 'cd', 'XX')
abXXefabXXef
reverse(
str
)
text
回傳反轉字串。
reverse('abcde')
edcba
right(
str
text
, n
int
)
text
回傳字串中的最後 n 個字元。當 n 為負數時,回傳除了第一個 |n| 之外的所有字元。
right('abcde', 2)
de
rpad(
string
text
, length
int
[,fill
text
])
text
透過附加字元 fill(預設為空格)將字串填充至長度 length。如果字串已經長於 length,那麼它將被截斷。
rpad('hi', 5, 'xy')
hixyx
rtrim(
string
text
[, characters
text
])
text
從字串末尾刪除最長某包含 characters (預設為空格)的字串
rtrim('testxxzx', 'xyz')
test
split_part(
string
text
,delimiter
text
, field
int
)
text
在分隔字上拆分字串並回傳給定段落(從一個字元開始)
split_part('abc~@~def~@~ghi', '~@~', 2)
def
strpos(
string
, substring
)
int
回傳子字串的位置(與 position 相同,但請注意參數順序不同)
strpos('high', 'ig')
2
substr(
string
, from
[, count
])
text
提取子字串(與 substring 相同)
substr('alphabet', 3, 2)
ph
to_ascii(
string
text
[, encoding
text
])
text
從其他編碼將字串轉換為 ASCII(僅支援從 LATIN1,LATIN2,LATIN9 和 WIN1250 編碼轉換)
to_ascii('Karel')
Karel
to_hex(
number
int
or bigint
)
text
將數字轉換為其等效的十六進位表示
to_hex(2147483647)
7fffffff
translate(
string
text
, from
text
, to
text
)
text
字串中與 from 集合中相符合的任何字元都將替換為 to 集合中的相對應字元。如果 from 長於 to,則會刪除 from 中出現的額外字元。
translate('12345', '143', 'ax')
a2x5
Conversion Name [a]
Source Encoding
Destination Encoding
ascii_to_mic
SQL_ASCII
MULE_INTERNAL
ascii_to_utf8
SQL_ASCII
UTF8
big5_to_euc_tw
BIG5
EUC_TW
big5_to_mic
BIG5
MULE_INTERNAL
big5_to_utf8
BIG5
UTF8
euc_cn_to_mic
EUC_CN
MULE_INTERNAL
euc_cn_to_utf8
EUC_CN
UTF8
euc_jp_to_mic
EUC_JP
MULE_INTERNAL
euc_jp_to_sjis
EUC_JP
SJIS
euc_jp_to_utf8
EUC_JP
UTF8
euc_kr_to_mic
EUC_KR
MULE_INTERNAL
euc_kr_to_utf8
EUC_KR
UTF8
euc_tw_to_big5
EUC_TW
BIG5
euc_tw_to_mic
EUC_TW
MULE_INTERNAL
euc_tw_to_utf8
EUC_TW
UTF8
gb18030_to_utf8
GB18030
UTF8
gbk_to_utf8
GBK
UTF8
iso_8859_10_to_utf8
LATIN6
UTF8
iso_8859_13_to_utf8
LATIN7
UTF8
iso_8859_14_to_utf8
LATIN8
UTF8
iso_8859_15_to_utf8
LATIN9
UTF8
iso_8859_16_to_utf8
LATIN10
UTF8
iso_8859_1_to_mic
LATIN1
MULE_INTERNAL
iso_8859_1_to_utf8
LATIN1
UTF8
iso_8859_2_to_mic
LATIN2
MULE_INTERNAL
iso_8859_2_to_utf8
LATIN2
UTF8
iso_8859_2_to_windows_1250
LATIN2
WIN1250
iso_8859_3_to_mic
LATIN3
MULE_INTERNAL
iso_8859_3_to_utf8
LATIN3
UTF8
iso_8859_4_to_mic
LATIN4
MULE_INTERNAL
iso_8859_4_to_utf8
LATIN4
UTF8
iso_8859_5_to_koi8_r
ISO_8859_5
KOI8R
iso_8859_5_to_mic
ISO_8859_5
MULE_INTERNAL
iso_8859_5_to_utf8
ISO_8859_5
UTF8
iso_8859_5_to_windows_1251
ISO_8859_5
WIN1251
iso_8859_5_to_windows_866
ISO_8859_5
WIN866
iso_8859_6_to_utf8
ISO_8859_6
UTF8
iso_8859_7_to_utf8
ISO_8859_7
UTF8
iso_8859_8_to_utf8
ISO_8859_8
UTF8
iso_8859_9_to_utf8
LATIN5
UTF8
johab_to_utf8
JOHAB
UTF8
koi8_r_to_iso_8859_5
KOI8R
ISO_8859_5
koi8_r_to_mic
KOI8R
MULE_INTERNAL
koi8_r_to_utf8
KOI8R
UTF8
koi8_r_to_windows_1251
KOI8R
WIN1251
koi8_r_to_windows_866
KOI8R
WIN866
koi8_u_to_utf8
KOI8U
UTF8
mic_to_ascii
MULE_INTERNAL
SQL_ASCII
mic_to_big5
MULE_INTERNAL
BIG5
mic_to_euc_cn
MULE_INTERNAL
EUC_CN
mic_to_euc_jp
MULE_INTERNAL
EUC_JP
mic_to_euc_kr
MULE_INTERNAL
EUC_KR
mic_to_euc_tw
MULE_INTERNAL
EUC_TW
mic_to_iso_8859_1
MULE_INTERNAL
LATIN1
mic_to_iso_8859_2
MULE_INTERNAL
LATIN2
mic_to_iso_8859_3
MULE_INTERNAL
LATIN3
mic_to_iso_8859_4
MULE_INTERNAL
LATIN4
mic_to_iso_8859_5
MULE_INTERNAL
ISO_8859_5
mic_to_koi8_r
MULE_INTERNAL
KOI8R
mic_to_sjis
MULE_INTERNAL
SJIS
mic_to_windows_1250
MULE_INTERNAL
WIN1250
mic_to_windows_1251
MULE_INTERNAL
WIN1251
mic_to_windows_866
MULE_INTERNAL
WIN866
sjis_to_euc_jp
SJIS
EUC_JP
sjis_to_mic
SJIS
MULE_INTERNAL
sjis_to_utf8
SJIS
UTF8
tcvn_to_utf8
WIN1258
UTF8
uhc_to_utf8
UHC
UTF8
utf8_to_ascii
UTF8
SQL_ASCII
utf8_to_big5
UTF8
BIG5
utf8_to_euc_cn
UTF8
EUC_CN
utf8_to_euc_jp
UTF8
EUC_JP
utf8_to_euc_kr
UTF8
EUC_KR
utf8_to_euc_tw
UTF8
EUC_TW
utf8_to_gb18030
UTF8
GB18030
utf8_to_gbk
UTF8
GBK
utf8_to_iso_8859_1
UTF8
LATIN1
utf8_to_iso_8859_10
UTF8
LATIN6
utf8_to_iso_8859_13
UTF8
LATIN7
utf8_to_iso_8859_14
UTF8
LATIN8
utf8_to_iso_8859_15
UTF8
LATIN9
utf8_to_iso_8859_16
UTF8
LATIN10
utf8_to_iso_8859_2
UTF8
LATIN2
utf8_to_iso_8859_3
UTF8
LATIN3
utf8_to_iso_8859_4
UTF8
LATIN4
utf8_to_iso_8859_5
UTF8
ISO_8859_5
utf8_to_iso_8859_6
UTF8
ISO_8859_6
utf8_to_iso_8859_7
UTF8
ISO_8859_7
utf8_to_iso_8859_8
UTF8
ISO_8859_8
utf8_to_iso_8859_9
UTF8
LATIN5
utf8_to_johab
UTF8
JOHAB
utf8_to_koi8_r
UTF8
KOI8R
utf8_to_koi8_u
UTF8
KOI8U
utf8_to_sjis
UTF8
SJIS
utf8_to_tcvn
UTF8
WIN1258
utf8_to_uhc
UTF8
UHC
utf8_to_windows_1250
UTF8
WIN1250
utf8_to_windows_1251
UTF8
WIN1251
utf8_to_windows_1252
UTF8
WIN1252
utf8_to_windows_1253
UTF8
WIN1253
utf8_to_windows_1254
UTF8
WIN1254
utf8_to_windows_1255
UTF8
WIN1255
utf8_to_windows_1256
UTF8
WIN1256
utf8_to_windows_1257
UTF8
WIN1257
utf8_to_windows_866
UTF8
WIN866
utf8_to_windows_874
UTF8
WIN874
windows_1250_to_iso_8859_2
WIN1250
LATIN2
windows_1250_to_mic
WIN1250
MULE_INTERNAL
windows_1250_to_utf8
WIN1250
UTF8
windows_1251_to_iso_8859_5
WIN1251
ISO_8859_5
windows_1251_to_koi8_r
WIN1251
KOI8R
windows_1251_to_mic
WIN1251
MULE_INTERNAL
windows_1251_to_utf8
WIN1251
UTF8
windows_1251_to_windows_866
WIN1251
WIN866
windows_1252_to_utf8
WIN1252
UTF8
windows_1256_to_utf8
WIN1256
UTF8
windows_866_to_iso_8859_5
WIN866
ISO_8859_5
windows_866_to_koi8_r
WIN866
KOI8R
windows_866_to_mic
WIN866
MULE_INTERNAL
windows_866_to_utf8
WIN866
UTF8
windows_866_to_windows_1251
WIN866
WIN
windows_874_to_utf8
WIN874
UTF8
euc_jis_2004_to_utf8
EUC_JIS_2004
UTF8
utf8_to_euc_jis_2004
UTF8
EUC_JIS_2004
shift_jis_2004_to_utf8
SHIFT_JIS_2004
UTF8
utf8_to_shift_jis_2004
UTF8
SHIFT_JIS_2004
euc_jis_2004_to_shift_jis_2004
EUC_JIS_2004
SHIFT_JIS_2004
shift_jis_2004_to_euc_jis_2004
SHIFT_JIS_2004
EUC_JIS_2004
[a] 轉換名稱遵循標準命名方式:原始碼的正式名稱,所有非字母數字字元替換為底線,後接to,後接類似處理的目標編碼名稱。因此,名稱可能會偏離慣用的編碼名稱。
Function
Description
Example
Example Result
num_nonnulls(VARIADIC "any")
returns the number of non-null arguments
num_nonnulls(1, NULL, 2)
2
num_nulls(VARIADIC "any")
returns the number of null arguments
num_nulls(1, NULL, 2)
1
Pattern
Description
HH
hour of day (01-12)
HH12
hour of day (01-12)
HH24
hour of day (00-23)
MI
minute (00-59)
SS
second (00-59)
MS
millisecond (000-999)
US
microsecond (000000-999999)
SSSS
seconds past midnight (0-86399)
AM
,am
,PM
orpm
meridiem indicator (without periods)
A.M.
,a.m.
,P.M.
orp.m.
meridiem indicator (with periods)
Y,YYY
year (4 or more digits) with comma
YYYY
year (4 or more digits)
YYY
last 3 digits of year
YY
last 2 digits of year
Y
last digit of year
IYYY
ISO 8601 week-numbering year (4 or more digits)
IYY
last 3 digits of ISO 8601 week-numbering year
IY
last 2 digits of ISO 8601 week-numbering year
I
last digit of ISO 8601 week-numbering year
BC
,bc
,AD
orad
era indicator (without periods)
B.C.
,b.c.
,A.D.
ora.d.
era indicator (with periods)
MONTH
full upper case month name (blank-padded to 9 chars)
Month
full capitalized month name (blank-padded to 9 chars)
month
full lower case month name (blank-padded to 9 chars)
MON
abbreviated upper case month name (3 chars in English, localized lengths vary)
Mon
abbreviated capitalized month name (3 chars in English, localized lengths vary)
mon
abbreviated lower case month name (3 chars in English, localized lengths vary)
MM
month number (01-12)
DAY
full upper case day name (blank-padded to 9 chars)
Day
full capitalized day name (blank-padded to 9 chars)
day
full lower case day name (blank-padded to 9 chars)
DY
abbreviated upper case day name (3 chars in English, localized lengths vary)
Dy
abbreviated capitalized day name (3 chars in English, localized lengths vary)
dy
abbreviated lower case day name (3 chars in English, localized lengths vary)
DDD
day of year (001-366)
IDDD
day of ISO 8601 week-numbering year (001-371; day 1 of the year is Monday of the first ISO week)
DD
day of month (01-31)
D
day of the week, Sunday (1
) to Saturday (7
)
ID
ISO 8601 day of the week, Monday (1
) to Sunday (7
)
W
week of month (1-5) (the first week starts on the first day of the month)
WW
week number of year (1-53) (the first week starts on the first day of the year)
IW
week number of ISO 8601 week-numbering year (01-53; the first Thursday of the year is in week 1)
CC
century (2 digits) (the twenty-first century starts on 2001-01-01)
J
Julian Day (integer days since November 24, 4714 BC at midnight UTC)
Q
quarter
RM
month in upper case Roman numerals (I-XII; I=January)
rm
month in lower case Roman numerals (i-xii; i=January)
TZ
upper case time-zone abbreviation (only supported into_char
)
tz
lower case time-zone abbreviation (only supported into_char
)
OF
time-zone offset from UTC (only supported into_char
)
Modifier
Description
Example
FM
prefix
fill mode (suppress leading zeroes and padding blanks)
FMMonth
TH
suffix
upper case ordinal number suffix
DDTH
, e.g.,12TH
th
suffix
lower case ordinal number suffix
DDth
, e.g.,12th
FX
prefix
fixed format global option (see usage notes)
FX Month DD Day
TM
prefix
translation mode (print localized day and month names based onlc_time)
TMMonth
SP
suffix
spell mode (not implemented)
DDSP
Pattern
Description
9
value with the specified number of digits
0
value with leading zeros
.
(period)
decimal point
,
(comma)
group (thousand) separator
PR
negative value in angle brackets
S
sign anchored to number (uses locale)
L
currency symbol (uses locale)
D
decimal point (uses locale)
G
group separator (uses locale)
MI
minus sign in specified position (if number < 0)
PL
plus sign in specified position (if number > 0)
SG
plus/minus sign in specified position
RN
Roman numeral (input between 1 and 3999)
TH
orth
ordinal number suffix
V
shift specified number of digits (see notes)
EEEE
exponent for scientific notation
Modifier
Description
Example
FM
prefix
fill mode (suppress leading zeroes and padding blanks)
FM9999
TH
suffix
upper case ordinal number suffix
999TH
th
suffix
lower case ordinal number suffix
999th
Expression
Result
to_char(current_timestamp, 'Day, DD HH12:MI:SS')
'Tuesday , 06 05:39:18'
to_char(current_timestamp, 'FMDay, FMDD HH12:MI:SS')
'Tuesday, 6 05:39:18'
to_char(-0.1, '99.99')
' -.10'
to_char(-0.1, 'FM9.99')
'-.1'
to_char(0.1, '0.9')
' 0.1'
to_char(12, '9990999.9')
' 0012.0'
to_char(12, 'FM9990999.9')
'0012.'
to_char(485, '999')
' 485'
to_char(-485, '999')
'-485'
to_char(485, '9 9 9')
' 4 8 5'
to_char(1485, '9,999')
' 1,485'
to_char(1485, '9G999')
' 1 485'
to_char(148.5, '999.999')
' 148.500'
to_char(148.5, 'FM999.999')
'148.5'
to_char(148.5, 'FM999.990')
'148.500'
to_char(148.5, '999D999')
' 148,500'
to_char(3148.5, '9G999D999')
' 3 148,500'
to_char(-485, '999S')
'485-'
to_char(-485, '999MI')
'485-'
to_char(485, '999MI')
'485 '
to_char(485, 'FM999MI')
'485'
to_char(485, 'PL999')
'+485'
to_char(485, 'SG999')
'+485'
to_char(-485, 'SG999')
'-485'
to_char(-485, '9SG99')
'4-85'
to_char(-485, '999PR')
'<485>'
to_char(485, 'L999')
'DM 485'
to_char(485, 'RN')
' CDLXXXV'
to_char(485, 'FMRN')
'CDLXXXV'
to_char(5.2, 'FMRN')
'V'
to_char(482, '999th')
' 482nd'
to_char(485, '"Good number:"999')
'Good number: 485'
to_char(485.8, '"Pre:"999" Post:" .999')
'Pre: 485 Post: .800'
to_char(12, '99V999')
' 12000'
to_char(12.4, '99V999')
' 12400'
to_char(12.45, '99V9')
' 125'
to_char(0.0004859, '9.99EEEE')
' 4.86e-04'
Function
Return Type
Description
Example
Result
abs(x
)
(same as input)
absolute value
abs(-17.4)
17.4
cbrt(dp
)
dp
cube root
cbrt(27.0)
3
ceil(dp
ornumeric
)
(same as input)
nearest integer greater than or equal to argument
ceil(-42.8)
-42
ceiling(dp
ornumeric
)
(same as input)
nearest integer greater than or equal to argument (same asceil
)
ceiling(-95.3)
-95
degrees(dp
)
dp
radians to degrees
degrees(0.5)
28.6478897565412
div(ynumeric
,xnumeric
)
numeric
integer quotient ofy
/x
div(9,4)
2
exp(dp
ornumeric
)
(same as input)
exponential
exp(1.0)
2.71828182845905
floor(dp
ornumeric
)
(same as input)
nearest integer less than or equal to argument
floor(-42.8)
-43
ln(dp
ornumeric
)
(same as input)
natural logarithm
ln(2.0)
0.693147180559945
log(dp
ornumeric
)
(same as input)
base 10 logarithm
log(100.0)
2
log(bnumeric
,xnumeric
)
numeric
logarithm to baseb
log(2.0, 64.0)
6.0000000000
mod(y
,x
)
(same as argument types)
remainder ofy
/x
mod(9,4)
1
pi()
dp
“π”constant
pi()
3.14159265358979
power(adp
,bdp
)
dp
a
_raised to the power ofb
_
power(9.0, 3.0)
729
power(anumeric
,bnumeric
)
numeric
a
_raised to the power ofb
_
power(9.0, 3.0)
729
radians(dp
)
dp
degrees to radians
radians(45.0)
0.785398163397448
round(dp
ornumeric
)
(same as input)
round to nearest integer
round(42.4)
42
round(vnumeric
,sint
)
numeric
round to_s
_decimal places
round(42.4382, 2)
42.44
scale(numeric
)
integer
scale of the argument (the number of decimal digits in the fractional part)
scale(8.41)
2
sign(dp
ornumeric
)
(same as input)
sign of the argument (-1, 0, +1)
sign(-8.4)
-1
sqrt(dp
ornumeric
)
(same as input)
square root
sqrt(2.0)
1.4142135623731
trunc(dp
ornumeric
)
(same as input)
truncate toward zero
trunc(42.8)
42
trunc(vnumeric
,sint
)
numeric
truncate to_s
_decimal places
trunc(42.4382, 2)
42.43
width_bucket(operanddp
,b1dp
,b2dp
,countint
)
int
return the bucket number to whichoperand
_would be assigned in a histogram havingcount
equal-width buckets spanning the rangeb1
tob2
; returns0
orcount
_+1for an input outside the range
width_bucket(5.35, 0.024, 10.06, 5)
3
width_bucket(operandnumeric
,b1numeric
,b2numeric
,countint
)
int
return the bucket number to whichoperand
_would be assigned in a histogram havingcount
equal-width buckets spanning the rangeb1
tob2
; returns0
orcount
_+1for an input outside the range
width_bucket(5.35, 0.024, 10.06, 5)
3
width_bucket(operandanyelement
,thresholdsanyarray
)
int
return the bucket number to whichoperand
_would be assigned given an array listing the lower bounds of the buckets; returns0
for an input less than the first lower bound; thethresholds
array_must be sorted, smallest first, or unexpected results will be obtained
width_bucket(now(), array['yesterday', 'today', 'tomorrow']::timestamptz[])
2
Function
Return Type
Description
random()
dp
random value in the range 0.0 <= x < 1.0
setseed(dp
)
void
set seed for subsequentrandom()
calls (value between -1.0 and 1.0, inclusive)
Function (radians)
Function (degrees)
Description
acos(x
)
acosd(x
)
inverse cosine
asin(x
)
asind(x
)
inverse sine
atan(x
)
atand(x
)
inverse tangent
atan2(y
,x
)
atan2d(y
,x
)
inverse tangent ofy
/x
cos(x
)
cosd(x
)
cosine
cot(x
)
cotd(x
)
cotangent
sin(x
)
sind(x
)
sine
tan(x
)
tand(x
)
tangent
Function
Return Type
Description
Example
Result
abbrev(inet
)
text
abbreviated display format as text
abbrev(inet '10.1.0.0/16')
10.1.0.0/16
abbrev(cidr
)
text
abbreviated display format as text
abbrev(cidr '10.1.0.0/16')
10.1/16
broadcast(inet
)
inet
broadcast address for network
broadcast('192.168.1.5/24')
192.168.1.255/24
family(inet
)
int
extract family of address;4
for IPv4,6
for IPv6
family('::1')
6
host(inet
)
text
extract IP address as text
host('192.168.1.5/24')
192.168.1.5
hostmask(inet
)
inet
construct host mask for network
hostmask('192.168.23.20/30')
0.0.0.3
masklen(inet
)
int
extract netmask length
masklen('192.168.1.5/24')
24
netmask(inet
)
inet
construct netmask for network
netmask('192.168.1.5/24')
255.255.255.0
network(inet
)
cidr
extract network part of address
network('192.168.1.5/24')
192.168.1.0/24
set_masklen(inet
,int
)
inet
set netmask length forinet
value
set_masklen('192.168.1.5/24', 16)
192.168.1.5/16
set_masklen(cidr
,int
)
cidr
set netmask length forcidr
value
set_masklen('192.168.1.0/24'::cidr, 16)
192.168.0.0/16
text(inet
)
text
extract IP address and netmask length as text
text(inet '192.168.1.5')
192.168.1.5/32
inet_same_family(inet
,inet
)
boolean
are the addresses from the same family?
inet_same_family('192.168.1.5/24', '::1')
false
inet_merge(inet
,inet
)
cidr
the smallest network which includes both of the given networks
inet_merge('192.168.1.5/24', '192.168.2.5/24')
192.168.0.0/22
Function
Return Type
Description
Example
Result
trunc(macaddr
)
macaddr
set last 3 bytes to zero
trunc(macaddr '12:34:56:78:90:ab')
12:34:56:00:00:00
Function
Return Type
Description
Example
Result
trunc(macaddr8
)
macaddr8
set last 5 bytes to zero
trunc(macaddr8 '12:34:56:78:90:ab:cd:ef')
12:34:56:00:00:00:00:00
macaddr8_set7bit(macaddr8
)
macaddr8
set 7th bit to one, also known as modified EUI-64, for inclusion in an IPv6 address
macaddr8_set7bit(macaddr8 '00:34:56:ab:cd:ef')
02:34:56:ff:fe:ab:cd:ef
Function
Return Type
Description
Example
Result
age(timestamp, timestamp)
interval
參數間相減,產生一個使用年和月的帶有「符號」的結果,而不僅僅是幾天
age(timestamp '2001-04-10', timestamp '1957-06-13')
43 years 9 mons 27 days
age(timestamp)
interval
用 current_date 減去該日期(以午夜為準)
age(timestamp '1957-06-13')
43 years 8 mons 3 days
clock_timestamp()
timestamp with time zone
Current date and time (changes during statement execution); see Section 9.9.4
current_date
date
目前日期;詳見第 9.9.4 節
current_time
time with time zone
Current time of day; see Section 9.9.4
current_timestamp
timestamp with time zone
Current date and time (start of current transaction); seeSection 9.9.4
date_part(text, timestamp)
double precision
Get subfield (equivalent to extract
); see Section 9.9.1
date_part('hour', timestamp '2001-02-16 20:38:40')
20
date_part(text, interval)
double precision
Get subfield (equivalent to extract
); see Section 9.9.1
date_part('month', interval '2 years 3 months')
3
date_trunc(text, timestamp)
timestamp
Truncate to specified precision; see also Section 9.9.2
date_trunc('hour', timestamp '2001-02-16 20:38:40')
2001-02-16 20:00:00
date_trunc(text, interval)
interval
Truncate to specified precision; see also Section 9.9.2
date_trunc('hour', interval '2 days 3 hours 40 minutes')
2 days 03:00:00
extract
(field from timestamp)
double precision
Get subfield; see Section 9.9.1
extract(hour from timestamp '2001-02-16 20:38:40')
20
extract
(field from interval)
double precision
Get subfield; see Section 9.9.1
extract(month from interval '2 years 3 months')
3
isfinite(date)
boolean
Test for finite date (not +/-infinity)
isfinite(date '2001-02-16')
true
isfinite(timestamp)
boolean
Test for finite time stamp (not +/-infinity)
isfinite(timestamp '2001-02-16 21:28:30')
true
isfinite(interval)
boolean
Test for finite interval
isfinite(interval '4 hours')
true
justify_days(interval)
interval
Adjust interval so 30-day time periods are represented as months
justify_days(interval '35 days')
1 mon 5 days
justify_hours(interval)
interval
Adjust interval so 24-hour time periods are represented as days
justify_hours(interval '27 hours')
1 day 03:00:00
justify_interval(interval)
interval
Adjust interval using justify_days
and justify_hours
, with additional sign adjustments
justify_interval(interval '1 mon -1 hour')
29 days 23:00:00
localtime
time
Current time of day; see Section 9.9.4
localtimestamp
timestamp
Current date and time (start of current transaction); seeSection 9.9.4
make_date(year int, month int, day int)
date
Create date from year, month and day fields
make_date(2013, 7, 15)
2013-07-15
make_interval(years int DEFAULT 0, months int DEFAULT 0, weeksint DEFAULT 0, days int DEFAULT 0, hours int DEFAULT 0, mins intDEFAULT 0, secs double precision DEFAULT 0.0)
interval
Create interval from years, months, weeks, days, hours, minutes and seconds fields
make_interval(days := 10)
10 days
make_time(hour int, min int, sec double precision)
time
Create time from hour, minute and seconds fields
make_time(8, 15, 23.5)
08:15:23.5
make_timestamp(year int, month int, day int, hour int, min int,sec double precision)
timestamp
Create timestamp from year, month, day, hour, minute and seconds fields
make_timestamp(2013, 7, 15, 8, 15, 23.5)
2013-07-15 08:15:23.5
make_timestamptz(year int, month int, day int, hour int, min int,sec double precision, [ timezone text ])
timestamp with time zone
Create timestamp with time zone from year, month, day, hour, minute and seconds fields. When timezone is not specified, then current time zone is used.
make_timestamptz(2013, 7, 15, 8, 15, 23.5)
2013-07-15 08:15:23.5+01
now()
timestamp with time zone
Current date and time (start of current transaction); seeSection 9.9.4
statement_timestamp()
timestamp with time zone
Current date and time (start of current statement); seeSection 9.9.4
timeofday()
text
Current date and time (like clock_timestamp
, but as a textstring); see Section 9.9.4
transaction_timestamp()
timestamp with time zone
Current date and time (start of current transaction); seeSection 9.9.4
microseconds
milliseconds
second
minute
hour
day
week
month
quarter
year
decade
century
millennium
Expression
Return Type
Description
timestamp without time zone AT TIME ZONE zone
timestamp with time zone
Treat given time stamp without time zone as located in the specified time zone
timestamp with time zone AT TIME ZONE zone
timestamp without time zone
Convert given time stamp with time zone to the new time zone, with no time zone designation
time with time zone AT TIME ZONE zone
time with time zone
Convert given time with time zone to the new time zone
Warning
Make sure that your session does not hold more locks than necessary when calling pg_sleep
or its variants. Otherwise other sessions might have to wait for your sleeping process, slowing down the entire system.
60 if leap seconds are implemented by the operating system
Function
Return Type
Description
Example
area(object
)
double precision
area
area(box '((0,0),(1,1))')
center(object
)
point
center
center(box '((0,0),(1,2))')
diameter(circle
)
double precision
diameter of circle
diameter(circle '((0,0),2.0)')
height(box
)
double precision
vertical size of box
height(box '((0,0),(1,1))')
isclosed(path
)
boolean
a closed path?
isclosed(path '((0,0),(1,1),(2,0))')
isopen(path
)
boolean
an open path?
isopen(path '[(0,0),(1,1),(2,0)]')
length(object
)
double precision
length
length(path '((-1,0),(1,0))')
npoints(path
)
int
number of points
npoints(path '[(0,0),(1,1),(2,0)]')
npoints(polygon
)
int
number of points
npoints(polygon '((1,1),(0,0))')
pclose(path
)
path
convert path to closed
pclose(path '[(0,0),(1,1),(2,0)]')
popen(path
)
path
convert path to open
popen(path '((0,0),(1,1),(2,0))')
radius(circle
)
double precision
radius of circle
radius(circle '((0,0),2.0)')
width(box
)
double precision
horizontal size of box
width(box '((0,0),(1,1))')
Function
Return Type
Description
Example
box(circle
)
box
circle to box
box(circle '((0,0),2.0)')
box(point
)
box
point to empty box
box(point '(0,0)')
box(point
,point
)
box
points to box
box(point '(0,0)', point '(1,1)')
box(polygon
)
box
polygon to box
box(polygon '((0,0),(1,1),(2,0))')
bound_box(box
,box
)
box
boxes to bounding box
bound_box(box '((0,0),(1,1))', box '((3,3),(4,4))')
circle(box
)
circle
box to circle
circle(box '((0,0),(1,1))')
circle(point
,double precision
)
circle
center and radius to circle
circle(point '(0,0)', 2.0)
circle(polygon
)
circle
polygon to circle
circle(polygon '((0,0),(1,1),(2,0))')
line(point
,point
)
line
points to line
line(point '(-1,0)', point '(1,0)')
lseg(box
)
lseg
box diagonal to line segment
lseg(box '((-1,0),(1,0))')
lseg(point
,point
)
lseg
points to line segment
lseg(point '(-1,0)', point '(1,0)')
path(polygon
)
path
polygon to path
path(polygon '((0,0),(1,1),(2,0))')
point
(double precision
,double precision
)
point
construct point
point(23.4, -44.5)
point(box
)
point
center of box
point(box '((-1,0),(1,0))')
point(circle
)
point
center of circle
point(circle '((0,0),2.0)')
point(lseg
)
point
center of line segment
point(lseg '((-1,0),(1,0))')
point(polygon
)
point
center of polygon
point(polygon '((0,0),(1,1),(2,0))')
polygon(box
)
polygon
box to 4-point polygon
polygon(box '((0,0),(1,1))')
polygon(circle
)
polygon
circle to 12-point polygon
polygon(circle '((0,0),2.0)')
polygon(npts
,circle
)
polygon
circle tonpts
-point polygon
polygon(12, circle '((0,0),2.0)')
polygon(path
)
polygon
path to polygon
polygon(path '((0,0),(1,1),(2,0))')
expression operator expression
(雙元中置運算子)
operator expression
(單元前置運算子)
expression operator
(單元後置運算子)
Operator
Description
Example
Result
`
`
concatenation
`B'10001'
B'011'`
10001011
&
bitwise AND
B'10001' & B'01101'
00001
`
`
bitwise OR
`B'10001'
B'01101'`
11101
#
bitwise XOR
B'10001' # B'01101'
11100
~
bitwise NOT
~ B'10001'
01110
<<
bitwise shift left
B'10001' << 3
01000
>>
bitwise shift right
B'10001' >> 2
00100
Function
Return Type
Description
Example
Result
string
||
string
text
字串連接
'Post' || 'greSQL'
PostgreSQL
string
||
non-string
or non-string
||
string
text
字串與一個非字串輸入連接
'Value: ' || 42
Value: 42
bit_length(
string
)
int
字串中的位元數
bit_length('jose')
32
char_length(
string
) or character_length(
string
)
int
字串中的字元數
char_length('jose')
4
lower(
string
)
text
將字串轉換為小寫
lower('TOM')
tom
octet_length(
string
)
int
字串中的位元組數
octet_length('jose')
4
overlay(
string
placing string
fromint
[for int
])
text
子字串替換
overlay('Txxxxas' placing 'hom' from 2 for 4)
Thomas
position(
substring
in string
)
int
指出子字串的位置
position('om' in 'Thomas')
3
substring(
string
[from int
] [forint
])
text
提取子字串
substring('Thomas' from 2 for 3)
hom
substring(
string
from pattern
)
text
提取符合 POSIX 正規表示式的子字串。有關特徵比對的更多訊息,請參見第 9.7 節。
substring('Thomas' from '...$')
mas
substring(
string
from pattern
forescape
)
text
提取符合 SQL 正規表示式的子字串。有關特徵比對的更多訊息,請參閱第 9.7 節。
substring('Thomas' from '%#"o_a#"_' for '#')
oma
trim([leading | trailing | both] [
characters
] from string
)
text
從字串的開頭,結尾或兩端(兩者都是預設值)中刪除包含某些字元(預設為空格)的最長字串
trim(both 'xyz' from 'yxTomxx')
Tom
trim([leading | trailing | both] [from]
string
[, characters
] )
text
trim() 的非標準語法
trim(both from 'yxTomxx', 'xyz')
Tom
upper(
string
)
text
將字串轉換為大寫
upper('tom')
TOM
Operator
Description
<
less than
>
greater than
<=
less than or equal to
>=
greater than or equal to
=
equal
<>
or!=
not equal
Predicate
Description
aBETWEENxANDy
between
aNOT BETWEENxANDy
not between
aBETWEEN SYMMETRICxANDy
between, after sorting the comparison values
aNOT BETWEEN SYMMETRICxANDy
not between, after sorting the comparison values
aIS DISTINCT FROMb
not equal, treating null like an ordinary value
aIS NOT DISTINCT FROMb
equal, treating null like an ordinary value
expressionIS NULL
is null
expressionIS NOT NULL
is not null
expressionISNULL
is null (nonstandard syntax)
expressionNOTNULL
is not null (nonstandard syntax)
boolean_expressionIS TRUE
is true
boolean_expressionIS NOT TRUE
is false or unknown
boolean_expressionIS FALSE
is false
boolean_expressionIS NOT FALSE
is true or unknown
boolean_expressionIS UNKNOWN
is unknown
boolean_expressionIS NOT UNKNOWN
is true or false
Function
Description
Example
Example Result
enum_first(anyenum)
Returns the first value of the input enum type
enum_first(null::rainbow)
red
enum_last(anyenum)
Returns the last value of the input enum type
enum_last(null::rainbow)
purple
enum_range(anyenum)
Returns all values of the input enum type in an ordered array
enum_range(null::rainbow)
{red,orange,yellow,green,blue,purple}
enum_range(anyenum, anyenum)
Returns the range between the two given enum values, as an ordered array. The values must be from the same enum type. If the first parameter is null, the result will start with the first value of the enum type. If the second parameter is null, the result will end with the last value of the enum type.
enum_range('orange'::rainbow, 'green'::rainbow)
{orange,yellow,green}
enum_range(NULL, 'green'::rainbow)
{red,orange,yellow,green}
enum_range('orange'::rainbow, NULL)
{orange,yellow,green,blue,purple}
Function
Return Type
Description
Example
to_char(timestamp
,text
)
text
convert time stamp to string
to_char(current_timestamp, 'HH12:MI:SS')
to_char(interval
,text
)
text
convert interval to string
to_char(interval '15h 2m 12s', 'HH24:MI:SS')
to_char(int
,text
)
text
convert integer to string
to_char(125, '999')
to_char
(double precision
,text
)
text
convert real/double precision to string
to_char(125.8::real, '999D9')
to_char(numeric
,text
)
text
convert numeric to string
to_char(-125.8, '999D99S')
to_date(text
,text
)
date
convert string to date
to_date('05 Dec 2000', 'DD Mon YYYY')
to_number(text
,text
)
numeric
convert string to numeric
to_number('12,454.8-', '99G999D9S')
to_timestamp(text
,text
)
timestamp with time zone
convert string to time stamp
to_timestamp('05 Dec 2000', 'DD Mon YYYY')
Operator
Description
Example
Result
+
addition
2 + 3
5
-
subtraction
2 - 3
-1
*
multiplication
2 * 3
6
/
division (integer division truncates the result)
4 / 2
2
%
modulo (remainder)
5 % 4
1
^
exponentiation (associates left to right)
2.0 ^ 3.0
8
`
/`
square root
`
/ 25.0`
5
`
/`
cube root
`
/ 27.0`
3
!
factorial
5 !
120
!!
factorial (prefix operator)
!! 5
120
@
absolute value
@ -5.0
5
&
bitwise AND
91 & 15
11
`
`
bitwise OR
`32
3`
35
#
bitwise XOR
17 # 5
20
~
bitwise NOT
~1
-2
<<
bitwise shift left
1 << 4
16
>>
bitwise shift right
8 >> 2
2
Function
Return Type
Description
Example
Result
string
`
_
string`_
bytea
String concatenation
`E'\\Post'::bytea
E'\047gres\000'::bytea`
\\Post'gres\000
octet_length(string
)
int
Number of bytes in binary string
octet_length(E'jo\\000se'::bytea)
5
overlay(string
_placingstring
_fromint
[forint
])
bytea
Replace substring
overlay(E'Th\\000omas'::bytea placing E'\\002\\003'::bytea from 2 for 3)
T\\002\\003mas
position(substring
_instring
_)
int
Location of specified substring
position(E'\\000om'::bytea in E'Th\\000omas'::bytea)
3
substring(string
[fromint
] [forint
])
bytea
Extract substring
substring(E'Th\\000omas'::bytea from 2 for 3)
h\000o
trim([both]bytes
_fromstring
_)
bytea
Remove the longest string containing only bytes appearing inbytes
_from the start and end ofstring
_
trim(E'\\000\\001'::bytea from E'\\000Tom\\001'::bytea)
Tom
Function
Return Type
Description
Example
Result
btrim(stringbytea
,bytesbytea
)
bytea
Remove the longest string containing only bytes appearing inbytes
_from the start and end ofstring
_
btrim(E'\\000trim\\001'::bytea, E'\\000\\001'::bytea)
trim
decode(stringtext
,formattext
)
bytea
Decode binary data from textual representation instring
. Options for_format
_are same as inencode
.
decode(E'123\\000456', 'escape')
123\000456
encode(databytea
,formattext
)
text
Encode binary data into a textual representation. Supported formats are:base64
,hex
,escape
.escape
converts zero bytes and high-bit-set bytes to octal sequences (\nnn
) and doubles backslashes.
encode(E'123\\000456'::bytea, 'escape')
123\000456
get_bit(string
,offset
)
int
Extract bit from string
get_bit(E'Th\\000omas'::bytea, 45)
1
get_byte(string
,offset
)
int
Extract byte from string
get_byte(E'Th\\000omas'::bytea, 4)
109
length(string
)
int
Length of binary string
length(E'jo\\000se'::bytea)
5
md5(string
)
text
Calculates the MD5 hash ofstring
, returning the result in hexadecimal
md5(E'Th\\000omas'::bytea)
8ab2d3c9689aaf18 b4958c334c82d8b1
set_bit(string
,offset
,newvalue
)
bytea
Set bit in string
set_bit(E'Th\\000omas'::bytea, 45, 0)
Th\000omAs
set_byte(string
,offset
,newvalue
)
bytea
Set byte in string
set_byte(E'Th\\000omas'::bytea, 4, 64)
Th\000o@as
Operator
Description
Example
<
is less than
inet '192.168.1.5' < inet '192.168.1.6'
<=
is less than or equal
inet '192.168.1.5' <= inet '192.168.1.5'
=
equals
inet '192.168.1.5' = inet '192.168.1.5'
>=
is greater or equal
inet '192.168.1.5' >= inet '192.168.1.5'
>
is greater than
inet '192.168.1.5' > inet '192.168.1.4'
<>
is not equal
inet '192.168.1.5' <> inet '192.168.1.4'
<<
is contained by
inet '192.168.1.5' << inet '192.168.1/24'
<<=
is contained by or equals
inet '192.168.1/24' <<= inet '192.168.1/24'
>>
contains
inet '192.168.1/24' >> inet '192.168.1.5'
>>=
contains or equals
inet '192.168.1/24' >>= inet '192.168.1/24'
&&
contains or is contained by
inet '192.168.1/24' && inet '192.168.1.80/28'
~
bitwise NOT
~ inet '192.168.1.6'
&
bitwise AND
inet '192.168.1.6' & inet '0.0.0.255'
`
`
bitwise OR
`inet '192.168.1.6'
inet '0.0.0.255'`
+
addition
inet '192.168.1.6' + 25
-
subtraction
inet '192.168.1.43' - 36
-
subtraction
inet '192.168.1.43' - inet '192.168.1.19'
Operator
Example
Result
+
date '2001-09-28' + integer '7'
date '2001-10-05'
+
date '2001-09-28' + interval '1 hour'
timestamp '2001-09-28 01:00:00'
+
date '2001-09-28' + time '03:00'
timestamp '2001-09-28 03:00:00'
+
interval '1 day' + interval '1 hour'
interval '1 day 01:00:00'
+
timestamp '2001-09-28 01:00' + interval '23 hours'
timestamp '2001-09-29 00:00:00'
+
time '01:00' + interval '3 hours'
time '04:00:00'
-
- interval '23 hours'
interval '-23:00:00'
-
date '2001-10-01' - date '2001-09-28'
integer '3' (days)
-
date '2001-10-01' - integer '7'
date '2001-09-24'
-
date '2001-09-28' - interval '1 hour'
timestamp '2001-09-27 23:00:00'
-
time '05:00' - time '03:00'
interval '02:00:00'
-
time '05:00' - interval '2 hours'
time '03:00:00'
-
timestamp '2001-09-28 23:00' - interval '23 hours'
timestamp '2001-09-28 00:00:00'
-
interval '1 day' - interval '1 hour'
interval '1 day -01:00:00'
-
timestamp '2001-09-29 03:00' - timestamp '2001-09-27 12:00'
interval '1 day 15:00:00'
*
900 * interval '1 second'
interval '00:15:00'
*
21 * interval '1 day'
interval '21 days'
*
double precision '3.5' * interval '1 hour'
interval '03:30:00'
/
interval '1 hour' / double precision '1.5'
interval '00:40:00'
Operator
Description
Example
+
Translation
box '((0,0),(1,1))' + point '(2.0,0)'
-
Translation
box '((0,0),(1,1))' - point '(2.0,0)'
*
Scaling/rotation
box '((0,0),(1,1))' * point '(2.0,0)'
/
Scaling/rotation
box '((0,0),(2,2))' / point '(2.0,0)'
#
Point or box of intersection
box '((1,-1),(-1,1))' # box '((1,1),(-2,-2))'
#
Number of points in path or polygon
# path '((1,0),(0,1),(-1,0))'
@-@
Length or circumference
@-@ path '((0,0),(1,0))'
@@
Center
@@ circle '((0,0),10)'
##
Closest point to first operand on second operand
point '(0,0)' ## lseg '((2,0),(0,2))'
<->
Distance between
circle '((0,0),1)' <-> circle '((5,0),1)'
&&
Overlaps? (One point in common makes this true.)
box '((0,0),(1,1))' && box '((0,0),(2,2))'
<<
Is strictly left of?
circle '((0,0),1)' << circle '((5,0),1)'
>>
Is strictly right of?
circle '((5,0),1)' >> circle '((0,0),1)'
&<
Does not extend to the right of?
box '((0,0),(1,1))' &< box '((0,0),(2,2))'
&>
Does not extend to the left of?
box '((0,0),(3,3))' &> box '((0,0),(2,2))'
`<<
`
Is strictly below?
`box '((0,0),(3,3))' <<
box '((3,4),(5,5))'`
`
>>`
Is strictly above?
`box '((3,4),(5,5))'
>> box '((0,0),(3,3))'`
`&<
`
Does not extend above?
`box '((0,0),(1,1))' &<
box '((0,0),(2,2))'`
`
&>`
Does not extend below?
`box '((0,0),(3,3))'
&> box '((0,0),(2,2))'`
<^
Is below (allows touching)?
circle '((0,0),1)' <^ circle '((0,5),1)'
>^
Is above (allows touching)?
circle '((0,5),1)' >^ circle '((0,0),1)'
?#
Intersects?
lseg '((-1,0),(1,0))' ?# box '((-2,-2),(2,2))'
?-
Is horizontal?
?- lseg '((-1,0),(1,0))'
?-
Are horizontally aligned?
point '(1,0)' ?- point '(0,0)'
`?
`
Is vertical?
`?
lseg '((-1,0),(1,0))'`
`?
`
Are vertically aligned?
`point '(0,1)' ?
point '(0,0)'`
`?-
`
Is perpendicular?
`lseg '((0,0),(0,1))' ?-
lseg '((0,0),(1,0))'`
`?
`
Are parallel?
`lseg '((-1,0),(1,0))' ?
lseg '((-1,2),(1,2))'`
@>
Contains?
circle '((0,0),2)' @> point '(1,1)'
<@
Contained in or on?
point '(1,1)' <@ circle '((0,0),2)'
~=
Same as?
polygon '((0,0),(1,1))' ~= polygon '((1,1),(0,0))'
版本:11
本節中描述的函數和類函數表示式對 xml 型別的值進行操作。有關 xml 型別的訊息,請查看第 8.13 節。這裡不再重複用於轉換為 xml 型別的函數表示式 xmlparse 和 xmlserialize。使用大多數這些函數需要使用 configure --with-libxml 編譯安裝。
一組函數和類函數的表示式可用於從 SQL 資料産生 XML 內容。因此,它們特別適合將查詢結果格式化為 XML 文件以便在用戶端應用程序中進行處理。
函數 xmlcomment 建立一個 XML 字串,其中包含指定文字作為內容的 XML 註釋。文字不能包含「 -- 」或以「 - 」結尾,以便産生的結構是有效的 XML 註釋。 如果參數為 null,則結果為 null。
例如:
函數 xmlconcat 連接列表中各個 XML 字串,以建立包含 XML 內容片段的單個字串。空值會被忽略;如果都沒有非空值參數,則結果僅為 null。
例如:
XML 宣告(如果存在)組合如下。如果所有參數值具有相同的 XML 版本宣告,則在結果中使用該版本,否則不使用任何版本。如果所有參數值都具有獨立宣告值「yes」,則在結果中使用該值。如果所有參數值都具有獨立的宣告值且至少有一個為「no」,則在結果中使用該值。否則結果將沒有獨立宣告。如果確定結果需要獨立宣告但沒有版本聲明,則將使用版本為 1.0 的版本宣告,因為 XML 要求 XML 宣告包含版本宣告。在所有情況下都會忽略編碼宣告並將其刪除。
例如:
xmlelement 表示式産生具有給定名稱、屬性和內容的 XML 元素。
範例:
透過用 xHHHH 序列替換有問題的字符來轉譯非有效 XML 名稱的元素和屬性名稱,其中 HHHH 是十六進位表示法中字元的 Unicode 代碼。例如:
如果屬性值是引用欄位,則無需明確指定屬性名稱,在這種情況下,預設情況下欄位的名稱將用作屬性名稱。在其他情況下,必須為該屬性明確指定名稱。所以這個例子是有效的:
但這些不行:
元素內容(如果已指定)將根據其資料型別進行格式化。如果內容本身是 xml 型別,則可以建構複雜的 XML 文件。例如:
其他型別的內容將被格式化為有效的 XML 字元資料。這尤其意味著字符 <、> 和 & 將被轉換為其他形式。二進位資料(資料型別 bytea)將以 base64 或十六進位編碼表示,具體取決於組態參數 xmlbinary 的設定。為了使 SQL 和 PostgreSQL 資料型別與 XML Schema 規範保持一致,預計各種資料型別的特定行為將會各自發展,此時將出現更精確的描述。
xmlforest 表示式使用給定的名稱和內容産生元素的 XML 序列。
範例:
如第二個範例所示,如果內容值是欄位引用,則可以省略元素名稱,在這種情況下,預設情況下使用欄位名稱。 否則,必須指定名稱。
非有效的 XML 名稱的元素名稱將被轉譯,如上面的 xmlelement 所示。類似地,內容資料會被轉譯以産生有效的 XML 內容,除非它已經是 xml 型別。
請注意,如果 XML 序列由多個元素組成,則它們不是有效的 XML 文件,因此將 xmlforest 表示式包裝在 xmlelement 中可能很有用。
xmlpi 表示式建立 XML 處理指令。內容(如果存在)不得包含字元序列 ?>。
例如:
xmlroot 表示式改變 XML 值的根節點屬性。如果指定了版本,它將替換根節點的版本宣告中的值;如果指定了獨立設定,則它將替換根節點的獨立宣告中的值。
與此處描述的其他函數不同,函數 xmlagg 是一個彙總函數。它將輸入值連接到彙總函數呼叫,就像 xmlconcat 一樣,除了它是跨資料列而不是在單個資料列中的表示式進行連接。有關彙總函數的其他訊息,請參閱第 9.20 節。
例如:
要確定連接的順序,可以將 ORDER BY 子句加到彙總呼叫中,如第 4.2.7 節中所述。例如:
以前的版本中推薦使用以下非標準方法,在特定情況下可能仍然有用:
本節中描述的表示式用於檢查 xml 的屬性。
如果參數 XML 是正確的 XML 文件,則表示式 IS DOCUMENT 將回傳 true,如果不是(它是內容片段),則回傳 false;如果參數為 null,則回傳 null。有關文件和內容片段之間的區別,請參閱第 8.13 節。
如果第一個參數中的 XPath 表示式回傳任何節點,則 xmlexists 函數回傳 true,否則回傳 false。 (如果任一參數為 null,則結果為 null。)
範例
BY REF 子句在 PostgreSQL 中沒有任何作用,但可以達到 SQL 一致性和與其他實作的相容性。根據 SQL 標準,第一個 BY REF 是必需的,第二個是選擇性的。另請注意,SQL 標準指定 xmlexists 構造將 XQuery 表示式作為第一個參數,但 PostgreSQL 目前僅支持 XPath,它是 XQuery 的子集。
此函數檢查文字字串是否格式正確,回傳布林結果。xml_is_well_formed_document 檢查格式正確的文檔,而 xml_is_well_formed_content 檢查格式良好的內容。如果 xmloption 配置參數設定為 DOCUMENT,則 xml_is_well_formed 會執行前者;如果設定為 CONTENT,則執行後者。這意味著 xml_is_well_formed 對於查看對 xml 類型的簡單強制轉換是否成功很有用,而其他兩個函數對於查看 XMLPARSE 的相對應變數是否成功很有用。
範例:
最後一個範例顯示檢查包括命名空間是否符合。
為了處理資料型別為 xml 的值,PostgreSQL 提供了 xpath 和 xpath_exists 函數,它們用於計算 XPath 1.0 表示式和 XMLTABLE 資料表函數。
函數 xpath 根據 XML 值 xml 計算 XPath 表示式 xpath(字串)。 它回傳與 XPath 表示式產生的節點集合所相對應 XML 值的陣列。如果 XPath 表示式回傳單一變數值而不是節點集合,則回傳單個元素的陣列。
第二個參數必須是格式良好的 XML 內容。特別要注意是,它必須具有單一根節點元素。
該函數的選擇性第三個參數是命名空間對應的陣列。該陣列應該是二維字串陣列,第二維的長度等於 2(即,它應該是陣列的陣列,每個陣列恰好由 2 個元素組成)。每個陣列項目的第一個元素是命名空間名稱(別名),第二個是命名空間 URI。不要求此陣列中提供的別名與 XML 內容本身所使用的別名相同(換句話說,在 XML 內容和 xpath 函數內容中,別名都是區域性的)。
例如:
要設定預設的(匿名)命名空間,請執行以下操作:
The function xpath_exists
is a specialized form of the xpath
function. Instead of returning the individual XML values that satisfy the XPath, this function returns a Boolean indicating whether the query was satisfied or not. This function is equivalent to the standard XMLEXISTS
predicate, except that it also offers support for a namespace mapping argument.
Example:
The xmltable
function produces a table based on the given XML value, an XPath filter to extract rows, and an optional set of column definitions.
The optional XMLNAMESPACES
clause is a comma-separated list of namespaces. It specifies the XML namespaces used in the document and their aliases. A default namespace specification is not currently supported.
The required row_expression
argument is an XPath expression that is evaluated against the supplied XML document to obtain an ordered sequence of XML nodes. This sequence is what xmltable
transforms into output rows.
document_expression
provides the XML document to operate on. The BY REF
clauses have no effect in PostgreSQL, but are allowed for SQL conformance and compatibility with other implementations. The argument must be a well-formed XML document; fragments/forests are not accepted.
The mandatory COLUMNS
clause specifies the list of columns in the output table. If the COLUMNS
clause is omitted, the rows in the result set contain a single column of type xml
containing the data matched by row_expression
. If COLUMNS
is specified, each entry describes a single column. See the syntax summary above for the format. The column name and type are required; the path, default and nullability clauses are optional.
A column marked FOR ORDINALITY
will be populated with row numbers matching the order in which the output rows appeared in the original input XML document. At most one column may be marked FOR ORDINALITY
.
The column_expression
for a column is an XPath expression that is evaluated for each row, relative to the result of the row_expression
, to find the value of the column. If no column_expression
is given, then the column name is used as an implicit path.
If a column's XPath expression returns multiple elements, an error is raised. If the expression matches an empty tag, the result is an empty string (not NULL
). Any xsi:nil
attributes are ignored.
The text body of the XML matched by the column_expression
is used as the column value. Multiple text()
nodes within an element are concatenated in order. Any child elements, processing instructions, and comments are ignored, but the text contents of child elements are concatenated to the result. Note that the whitespace-only text()
node between two non-text elements is preserved, and that leading whitespace on a text()
node is not flattened.
If the path expression does not match for a given row but default_expression
is specified, the value resulting from evaluating that expression is used. If no DEFAULT
clause is given for the column, the field will be set to NULL
. It is possible for a default_expression
to reference the value of output columns that appear prior to it in the column list, so the default of one column may be based on the value of another column.
Columns may be marked NOT NULL
. If the column_expression
for a NOT NULL
column does not match anything and there is no DEFAULT
or the default_expression
also evaluates to null, an error is reported.
Unlike regular PostgreSQL functions, column_expression
and default_expression
are not evaluated to a simple value before calling the function. column_expression
is normally evaluated exactly once per input row, and default_expression
is evaluated each time a default is needed for a field. If the expression qualifies as stable or immutable the repeat evaluation may be skipped. Effectively xmltable
behaves more like a subquery than a function call. This means that you can usefully use volatile functions like nextval
in default_expression
, and column_expression
may depend on other parts of the XML document.
Examples:
The following example shows concatenation of multiple text() nodes, usage of the column name as XPath filter, and the treatment of whitespace, XML comments and processing instructions:
The following example illustrates how the XMLNAMESPACES
clause can be used to specify the default namespace, and a list of additional namespaces used in the XML document as well as in the XPath expressions:
The following functions map the contents of relational tables to XML values. They can be thought of as XML export functionality:
The return type of each function is xml
.
table_to_xml
maps the content of the named table, passed as parameter tbl
. The regclass
type accepts strings identifying tables using the usual notation, including optional schema qualifications and double quotes. query_to_xml
executes the query whose text is passed as parameter query
and maps the result set. cursor_to_xml
fetches the indicated number of rows from the cursor specified by the parameter cursor
. This variant is recommended if large tables have to be mapped, because the result value is built up in memory by each function.
If tableforest
is false, then the resulting XML document looks like this:
If tableforest
is true, the result is an XML content fragment that looks like this:
If no table name is available, that is, when mapping a query or a cursor, the string table
is used in the first format, row
in the second format.
The choice between these formats is up to the user. The first format is a proper XML document, which will be important in many applications. The second format tends to be more useful in the cursor_to_xml
function if the result values are to be reassembled into one document later on. The functions for producing XML content discussed above, in particular xmlelement
, can be used to alter the results to taste.
The data values are mapped in the same way as described for the function xmlelement
above.
The parameter nulls
determines whether null values should be included in the output. If true, null values in columns are represented as:
where xsi
is the XML namespace prefix for XML Schema Instance. An appropriate namespace declaration will be added to the result value. If false, columns containing null values are simply omitted from the output.
The parameter targetns
specifies the desired XML namespace of the result. If no particular namespace is wanted, an empty string should be passed.
The following functions return XML Schema documents describing the mappings performed by the corresponding functions above:
It is essential that the same parameters are passed in order to obtain matching XML data mappings and XML Schema documents.
The following functions produce XML data mappings and the corresponding XML Schema in one document (or forest), linked together. They can be useful where self-contained and self-describing results are wanted:
In addition, the following functions are available to produce analogous mappings of entire schemas or the entire current database:
Note that these potentially produce a lot of data, which needs to be built up in memory. When requesting content mappings of large schemas or databases, it might be worthwhile to consider mapping the tables separately instead, possibly even through a cursor.
The result of a schema content mapping looks like this:
where the format of a table mapping depends on the tableforest
parameter as explained above.
The result of a database content mapping looks like this:
where the schema mapping is as above.
As an example of using the output produced by these functions, Figure 9.1 shows an XSLT stylesheet that converts the output of table_to_xml_and_xmlschema
to an HTML document containing a tabular rendition of the table data. In a similar manner, the results from these functions can be converted into other XML-based formats.
Table 9.40,Table 9.41andTable 9.42summarize the functions and operators that are provided for full text searching. SeeChapter 12for a detailed explanation ofPostgreSQL's text search facility.
Table 9.40. Text Search Operators
Operator
Return Type
Description
Example
Result
@@
boolean
tsvector
matchestsquery
?
to_tsvector('fat cats ate rats') @@ to_tsquery('cat & rat')
t
@@@
boolean
deprecated synonym for@@
to_tsvector('fat cats ate rats') @@@ to_tsquery('cat & rat')
t
`
`
tsvector
concatenatetsvector
s
`'a:1 b:2'::tsvector
'c:1 d:2 b:3'::tsvector`
'a':1 'b':2,5 'c':3 'd':4
&&
tsquery
ANDtsquery
s together
`'fat
rat'::tsquery && 'cat'::tsquery`
`( 'fat'
'rat' ) & 'cat'`
`
`
tsquery
ORtsquery
s together
`'fat
rat'::tsquery
'cat'::tsquery`
`( 'fat'
'rat' )
'cat'`
!!
tsquery
negate atsquery
!! 'cat'::tsquery
!'cat'
<->
tsquery
tsquery
followed bytsquery
to_tsquery('fat') <-> to_tsquery('rat')
'fat' <-> 'rat'
@>
boolean
tsquery
contains another ?
'cat'::tsquery @> 'cat & rat'::tsquery
f
<@
boolean
tsquery
is contained in ?
'cat'::tsquery <@ 'cat & rat'::tsquery
t
Thetsquery
containment operators consider only the lexemes listed in the two queries, ignoring the combining operators.
In addition to the operators shown in the table, the ordinary B-tree comparison operators (=
,<
, etc) are defined for typestsvector
andtsquery
. These are not very useful for text searching but allow, for example, unique indexes to be built on columns of these types.
Table 9.41. Text Search Functions
Function
Return Type
Description
Example
Result
array_to_tsvector(text[]
)
tsvector
convert array of lexemes totsvector
array_to_tsvector('{fat,cat,rat}'::text[])
'cat' 'fat' 'rat'
get_current_ts_config()
regconfig
get default text search configuration
get_current_ts_config()
english
length(tsvector
)
integer
number of lexemes intsvector
length('fat:2,4 cat:3 rat:5A'::tsvector)
3
numnode(tsquery
)
integer
number of lexemes plus operators intsquery
`numnode('(fat & rat)
cat'::tsquery)`
5
plainto_tsquery([configregconfig
,]querytext
)
tsquery
producetsquery
ignoring punctuation
plainto_tsquery('english', 'The Fat Rats')
'fat' & 'rat'
phraseto_tsquery([configregconfig
,]querytext
)
tsquery
producetsquery
that searches for a phrase, ignoring punctuation
phraseto_tsquery('english', 'The Fat Rats')
'fat' <-> 'rat'
querytree(querytsquery
)
text
get indexable part of atsquery
querytree('foo & ! bar'::tsquery)
'foo'
setweight(vectortsvector
,weight"char"
)
tsvector
assignweight
_to each element ofvector
_
setweight('fat:2,4 cat:3 rat:5B'::tsvector, 'A')
'cat':3A 'fat':2A,4A 'rat':5A
setweight(vectortsvector
,weight"char"
,lexemestext[]
)
tsvector
assignweight
_to elements ofvector
that are listed inlexemes
_
setweight('fat:2,4 cat:3 rat:5B'::tsvector, 'A', '{cat,rat}')
'cat':3A 'fat':2,4 'rat':5A
strip(tsvector
)
tsvector
remove positions and weights fromtsvector
strip('fat:2,4 cat:3 rat:5A'::tsvector)
'cat' 'fat' 'rat'
to_tsquery([configregconfig
,]querytext
)
tsquery
normalize words and convert totsquery
to_tsquery('english', 'The & Fat & Rats')
'fat' & 'rat'
to_tsvector([configregconfig
,]documenttext
)
tsvector
reduce document text totsvector
to_tsvector('english', 'The Fat Rats')
'fat':2 'rat':3
to_tsvector([configregconfig
,]documentjson(b)
)
tsvector
reduce each string value in the document to atsvector
, and then concatentate those in document order to produce a singletsvector
to_tsvector('english', '{"a": "The Fat Rats"}'::json)
'fat':2 'rat':3
ts_delete(vectortsvector
,lexemetext
)
tsvector
remove givenlexeme
_fromvector
_
ts_delete('fat:2,4 cat:3 rat:5A'::tsvector, 'fat')
'cat':3 'rat':5A
ts_delete(vectortsvector
,lexemestext[]
)
tsvector
remove any occurrence of lexemes inlexemes
_fromvector
_
ts_delete('fat:2,4 cat:3 rat:5A'::tsvector, ARRAY['fat','rat'])
'cat':3
ts_filter(vectortsvector
,weights"char"[]
)
tsvector
select only elements with givenweights
_fromvector
_
ts_filter('fat:2,4 cat:3b rat:5A'::tsvector, '{a,b}')
'cat':3B 'rat':5A
ts_headline([configregconfig
,]documenttext
,querytsquery
[,optionstext
])
text
display a query match
ts_headline('x y z', 'z'::tsquery)
x y <b>z</b>
ts_headline([configregconfig
,]documentjson(b)
,querytsquery
[,optionstext
])
text
display a query match
ts_headline('{"a":"x y z"}'::json, 'z'::tsquery)
{"a":"x y <b>z</b>"}
ts_rank([weightsfloat4[]
,]vectortsvector
,querytsquery
[,normalizationinteger
])
float4
rank document for query
ts_rank(textsearch, query)
0.818
ts_rank_cd([weightsfloat4[]
,]vectortsvector
,querytsquery
[,normalizationinteger
])
float4
rank document for query using cover density
ts_rank_cd('{0.1, 0.2, 0.4, 1.0}', textsearch, query)
2.01317
ts_rewrite(querytsquery
,targettsquery
,substitutetsquery
)
tsquery
replacetarget
_withsubstitute
_within query
`ts_rewrite('a & b'::tsquery, 'a'::tsquery, 'foo
bar'::tsquery)`
`'b' & ( 'foo'
'bar' )`
ts_rewrite(querytsquery
,selecttext
)
tsquery
replace using targets and substitutes from aSELECT
command
SELECT ts_rewrite('a & b'::tsquery, 'SELECT t,s FROM aliases')
`'b' & ( 'foo'
'bar' )`
tsquery_phrase(query1tsquery
,query2tsquery
)
tsquery
make query that searches forquery1
_followed byquery2
_(same as<->
operator)
tsquery_phrase(to_tsquery('fat'), to_tsquery('cat'))
'fat' <-> 'cat'
tsquery_phrase(query1tsquery
,query2tsquery
,distanceinteger
)
tsquery
make query that searches forquery1
_followed byquery2
at distancedistance
_
tsquery_phrase(to_tsquery('fat'), to_tsquery('cat'), 10)
'fat' <10> 'cat'
tsvector_to_array(tsvector
)
text[]
converttsvector
to array of lexemes
tsvector_to_array('fat:2,4 cat:3 rat:5A'::tsvector)
{cat,fat,rat}
tsvector_update_trigger()
trigger
trigger function for automatictsvector
column update
CREATE TRIGGER ... tsvector_update_trigger(tsvcol, 'pg_catalog.swedish', title, body)
tsvector_update_trigger_column()
trigger
trigger function for automatictsvector
column update
CREATE TRIGGER ... tsvector_update_trigger_column(tsvcol, configcol, title, body)
unnest(tsvector
, OUTlexemetext
, OUTpositionssmallint[]
, OUTweightstext
)
setof record
expand a tsvector to a set of rows
unnest('fat:2,4 cat:3 rat:5A'::tsvector)
(cat,{3},{D}) ...
All the text search functions that accept an optionalregconfig
argument will use the configuration specified bydefault_text_search_configwhen that argument is omitted.
The functions inTable 9.42are listed separately because they are not usually used in everyday text searching operations. They are helpful for development and debugging of new text search configurations.
Table 9.42. Text Search Debugging Functions
Function
Return Type
Description
Example
Result
ts_debug([configregconfig
,]documenttext
, OUTaliastext
, OUTdescriptiontext
, OUTtokentext
, OUTdictionariesregdictionary[]
, OUTdictionaryregdictionary
, OUTlexemestext[]
)
setof record
test a configuration
ts_debug('english', 'The Brightest supernovaes')
(asciiword,"Word, all ASCII",The,{english_stem},english_stem,{}) ...
ts_lexize(dictregdictionary
,tokentext
)
text[]
test a dictionary
ts_lexize('english_stem', 'stars')
{star}
ts_parse(parser_nametext
,documenttext
, OUTtokidinteger
, OUTtokentext
)
setof record
test a parser
ts_parse('default', 'foo - bar')
(1,foo) ...
ts_parse(parser_oidoid
,documenttext
, OUTtokidinteger
, OUTtokentext
)
setof record
test a parser
ts_parse(3722, 'foo - bar')
(1,foo) ...
ts_token_type(parser_nametext
, OUTtokidinteger
, OUTaliastext
, OUTdescriptiontext
)
setof record
get token types defined by parser
ts_token_type('default')
(1,asciiword,"Word, all ASCII") ...
ts_token_type(parser_oidoid
, OUTtokidinteger
, OUTaliastext
, OUTdescriptiontext
)
setof record
get token types defined by parser
ts_token_type(3722)
(1,asciiword,"Word, all ASCII") ...
ts_stat(sqlquerytext
, [weightstext
,] OUTwordtext
, OUTndocinteger
, OUTnentryinteger
)
setof record
get statistics of atsvector
column
ts_stat('SELECT vector from apod')
(foo,10,15) ...
PostgreSQL 允許函數呼叫的時候,使用編號或名稱記號。名稱記號特別好用在於有很多參數的時候,因為它能讓參數與實際的引數有更明確的關連,也更有信賴感。使用編號記號的話,函數呼叫就會依其宣告時的參數次序給予編號;而使用名稱記號的話,參數就會依宣告時的名稱配對,不需要次序對應。
不論哪一種記號方式,如果在宣告時有設定預設值的話,那就不一定要在呼叫時設定其值。不過這點對名稱記號特別好用,因為任何參數的組合都可以省略,而編號記號時就只有從最右邊的參數開始省略。
PostgreSQL 也支援混合式的記號方式,也就是同時使用編號,也使用名稱。在這個例子中,編號的參數會先使用,然後名稱的參數在其之後使用。
接下來的例子,將會描繪所有三種記號方式,都使用下列的函數定義:
函數 concat_lower_or_upper 有兩個必要的參數,a 與 b。然後有一個參數是選擇性的,uppercase 的預設值是 false。參數 a 和 b 的文字會被連結起來,然後依 uppercase 的設定,強制轉換為大寫或小寫字母。這個函數定義的其他部份在這裡並不重要(詳情請參閱第 37 章)。
編號記號是 PostgreSQL 傳統的參數呼叫方式,如下所示:
所有的參數會依序指定。結果是全大寫,因為 uppercase 設定為 true。另一個例子如下:
這裡的 uppercase 省略了,所以會使用預設值 false,結果就以小寫字母輸出。在編號的記號方式時,參數的省略是由右至左,只有具有預設值的部份才能省略。
使用名稱作為參數記號方式的話,每一個參數名使用「=>」來指定其所代表的表示式,如下所示:
In named notation, each argument's name is specified using=>
to separate it from the argument expression. For example:
再一次省略 uppercase,所以它自動設為 false。使用名稱記號的一項好處就是參數不用固定次數,如下例所示:
有一種比較舊的語法是使用「:=」,因為相容性而保留下來:
混用記號指的就是混合使用編號及名稱來設定參數。然而,如前所述,名稱參數不能先於編號參數。例如:
在上面的查詢中,a 和 b 兩個參數以編號指定,而 uppercase 就以名稱指定。在本例子,只有增加一點點內容而已。使用比較複雜的函數時,會有許多參數設定了預設值,以名稱或混合的方式來設定參數,可以節省許多撰寫的程式碼,也可以減少出錯的可能性。
名稱記號和混用記號目前不能用於彙總函數的呼叫(但如果是用於窗函數是就可以)。
SQL 語法包含一連串的命令,命令是由一系列的指示記號所組合而成,以分號結尾。最後如果是串流輸入,也會結束一個命令。指示的合法性是由特別的命令語法所定義的。
指示記號可能是關鍵字、識別項、引號識別項、文字、或一個特別的字元符號。指示一般來說是以空白分隔(空白符號、定位符號、換行符號),但如果不會混淆的話,也不一定需要。(一般只出現在特殊字元用來調整了其他指示的型別)
舉個例子,下面就是一個合法(符合語法)的 SQL 輸入:
這個序列包含了 3 個命令,每行一個(然而這不是一定的,同一行可以超過一個命令,而一個命令也可以分解為多行使用)。
順帶一提的是,註解也是 SQL 輸入的一部份,但不屬於任何指示記號,他們等同於空白字元。
SQL 語法並不是很嚴格要求什麼樣的指示記號來識別命令,或是哪些是運算子或參數。通常最前面的指示記號是命令的名稱,以上面的例子來說,我們通常會說是一個「SELECT」、一個「UPDATE」、以及一個「INSERT」命令。但對於 UPDATE 命令而言,有一個 SET 指示記號出現在某個地方是必要的;同樣地,INSERT 也需要有 VALUES 來搭配。精確的語法規則都在第 6 部份中的章節進行說明。
在上面的例子中的 SELECT、UPDATE、或是 VALUES,都是屬於關鍵字的範圍。所謂關鍵字,意即在 SQL 語言中,其具有固定的意義。像指示記號 MY_TABLE 則是屬於識別項。它識別表格的名稱,欄位名稱,或是其他的資料庫物件,端看命令如何看待該識別項。然而,有時候它們會被簡稱為「名稱」。關鍵字和識別項的文法結構是相同的,意即不看整個命令的話,是無法辨別到底是識別項還是關鍵字的。完整的關鍵字列表,收錄在附件 C 當中。
SQL 識別項與關鍵字必須以英文字母開頭(a - z,也可以是附加符號和非拉丁字母,中文沒問題)或是底線(_)。剩餘的字元可以是字母、底線、數字(0 - 9)、或錢字號($)。注意錢字號,在標準 SQL 語法中是不允許使用的,所以可能會降低一些應用程式的可攜性。標準 SQL 也沒有定義包含數字或是以底線起迄的關鍵字,所以識別項這樣的形式定義是安全的,不會和標準未來的修訂相衝突。
資料庫系統不能使用長度超過 NAMEDATALEN -1 的識別項;太長的名稱仍然可以在命令中被輸入,但會被截斷。預設上,NAMEDATALEN 的設定是 64,所以最長的識別項名稱長度是 63 位元組。如果這個限制會造成困擾的話,你也可以調整 NAMEDATALEN 的編譯值,它的設定在 src/include/pg_config_manual.h 檔案中。
關鍵字和無引號識別項都是不分大小寫的,所以:
等同於:
有一種寫法很常使用,就是把關鍵字用大寫表示,而識別項名稱使用小寫,例如:
第二種要介紹的識別項是,受限制的識別項,或是引號識別項。它的形式就是以雙引號括住的任何字串。受限制的識別項,就一定是識別項,不會是關鍵字。所以,「"select"」就會被識別為名稱為「select」的表格或欄位,而無引號的 select 就會被視為是關鍵字,也可能會產生解譯錯誤,如果剛好用在可能是表格或欄位名稱的位置上的話。使用引號識別項的例子如下:
引號識別項可以包含任何字元,除了字元碼為 0 的字元以外。(要包含雙引號字元的話,請使用連續兩個雙引號。)這可以用來建立原來不能使用的表格或欄位名稱,甚至是包含空白或"&"。但長度的限制仍然要遵守。
還有一種變形的引號識別項,允許包含跳脫的形式來表現萬國碼(unicode)。這種變形會以「U&」開頭(U大小寫皆可)緊接在前面的雙引號的前面,不能有任何空白在它們之間,例如:U&"foo"。(注意,這可能會和運算子的 & 產生混淆,但可以在運算子的 & 前後都加上空白來避免這個問題。)在雙引號內,萬國碼字元以跳脫的形式表現,也就是以倒斜線再接 4 位數的 16 進位碼,或倒斜線接一個加號再串一組 6 位數的 16 進位碼。例如,識別項 "data" 可以寫成這樣:
下面是稍微不簡明的例子是,俄文的"slon"(大象),以希伯萊文字母表現:
如果希望以不同的跳脫字元來代替倒斜線的話,那麼可以雙引號結束後使用 UESCAPE 子句來指定,舉例來說:
跳脫字元可以是任何的單一字元,除了 16 進位數字的字元、單引號、雙引號、或空白以外。注意指定的跳脫字元是以單引號括住,而不是雙引號。
內容要使用到跳脫字元的話,就重覆輸入 2 次。
萬國碼的跳脫語法,只能使用 UTF8 的編碼。如果有用到其他的編碼的話,只有在 ASCII 範圍(最大為 \007F)可以使用。4 位數及 6 位數的形式,可以組合配對用來指定 UTF-16 中,大於 U+FFFF 的字元,雖然 6 位數的形式單獨就可以解決這個問題(組合配對並不會直接被儲存起來,他們會被編碼成 UTF-8 再儲存。)
把識別項用引號括起來也可以用來保持它的大小寫狀態,沒有括起來的話,都會被轉成小寫字母。舉例來說,對 PostgreSQL 而言,FOO、foo、"foo",三者都是一樣的,但 "Foo" 和 "FOO" 就彼此及前面三者都視為不同。(在 PostgreSQL 中,把未引號括起的名稱轉成小寫,並不是 SQL 的標準。SQL 標準反而是都轉成大寫。所以在 SQL 標準中,foo 應該是等同於 "FOO" 而不同於 "foo"。如果你要增加語法的可攜性的話,建議最好都使用引號括起特別的名稱,或者都不要使用引號。)
PostgreSQL 中有三種隱含型別的常數:字串、位元字串、和數值。常數也可以強制型別,有助於更精確的表達,也可以讓系統處理更有效率。接下來就開始進行相關的說明。
在 SQL 中,所謂的字串常數,指的是用單引號括住的任意字元串列,例如:'This is a string'。如果在字串常數內需要有單引號的話就使用連續兩個單引號,例如:'Dianne''s horse'。注意這不是雙引號,是兩個單引號。
兩個字串常數如果只用空白及至少一個換行符號所分隔的話,那個它們會被連在一起,和寫成一個字串是一樣的。舉例來說:
等同於:
但如果是這樣:
語法上就不正確了。(這是來自於 SQL 奇怪的常規,PostgreSQL 單純只是遵循。)
PostgreSQL 也支援跳脫字串常數,這些是 SQL 標準的延伸。跳脫字串常數使用的是字母 E (大小寫皆可),緊接著單引號所組成,例如:E'foo'。(如果字串有超過一行的話,也只要在第一個單引號前有 E 就可以了。)在跳脫字串當中,使用倒斜線開頭,就可以使用 C 語言式的倒斜線跳脫字串,通常是一個倒斜線再接一個字元,對應到一個特殊位元組的值,如 Table 4.1 所示。
Table 4.1. 倒斜線跳腳字串(Backslash Escape Sequence)
倒斜線跳腳字串
字元意義
\b
backspace(倒退)
\f
form feed(換頁)
\n
newline(換行)
\r
carriage return(回到行首)
\t
tab(定位符號)
\o
,\oo
,\ooo
(o
= 0 - 7)
octal byte value(8 進位值)
\xh
,\xhh
(h
= 0 - 9, A - F)
hexadecimal byte value(16 進位值)
\uxxxx
,\Uxxxxxxxx
(x
= 0 - 9, A - F)
16 or 32-bit hexadecimal Unicode character value(16 位元或 32 位元的 16 進位萬國碼字元值)
任何其他接在倒斜線後面的字元都僅以原樣呈現。而如果要包含一個倒斜線的話,就使用連續兩個倒斜線輸入。同樣地,要包含一個單引號的話,可以使用跳脫字串 \' 輸入,也可以用一般連續兩個單引號的方式輸入。
你需要確保你所使用的 8 進位或 16 進位創建的位元組序列,都是屬於資料庫中合法的字元集。當資料庫編輯是 UTF-8 時,就應該使用萬國碼跳脫寫法,或其他萬國碼的輸入方式,如前 4.1.2.3 中所述。(所謂其他的方式可能是自行組合每一個位元組,但這樣會是相當麻煩的事。)
萬國碼跳脫語法只有在 UTF8 的編碼下才完整支援。當有其他的字元編碼被使用時,就只能使用 ASCII 的範圍(最大值為 \u007F)中的值。4 位數及 6 位數的型式可以用來配對指定 UTF-16 超過 U+FFFF 的字元,即使 6 位數的型式就足以解決這個問題。(當使用配對語法,且字元編碼為 UTF8 時,他們會先被合併成單一字元,然後再編碼成 UTF-8。)
如果設定檔參數 standard_conforming_string 設定為 off,PostgreSQL 不論在一般字串還是跳脫字串常數,都會把倒斜線識別為跳脫符號。然而,在 PostgreSQL 9.1 之前,這個參數的預設值為 on,表示只在跳脫字串常數裡,才把倒斜線視為跳脫符號。這樣的模式是更與標準相容的,但可能會破壞默認舊有設定的應用程式,也就是總是把倒斜線視為跳脫符號。在這樣的背景之下,你可以把這個參數設為 off,但更好的是,修改程式不再使用倒斜線跳脫符號。如果你需要使用倒斜線跳脫符號來表示一個特殊字元,請使用 E 開頭的字串常數。
有關 standard_conforming_string,順帶一提的是,還有 escape_string_warning 和 backslash_quote 兩個參數,也提供調整倒斜線在字串常數中的使用。
字元代碼 0 的字元不能使用在字串常數當中。
PostgreSQL 也支援其他跳脫字串的語法,可以用來直接輸入任意的萬國碼字元。萬國碼跳脫字串常數是以 U& (U& 或 u& 皆可)開頭,然後緊接著單引號括住的字串,記得中間不能有任何空白,例如:U&'foo'。(注意這可能會混淆到 & 的使用,最好在其他使用 & 作為運算子的指令中,在 & 前後 加上空白字元,以避免這個問題。)在括住的內容裡,萬國碼字元可以使用跳脫字元來指定,也就是使用倒斜線再接一組 4 位數的 16 進位值,或者以倒斜線加上加號再接一組 6 位數的 16 進位值。舉個例子,字串 'data' 也可以寫成:
下面是稍微不簡明的例子是,俄文的"slon"(大象),以希伯萊文字母表現:
如果希望以不同的跳脫字元來代替倒斜線的話,那麼可以雙引號結束後使用 UESCAPE 子句來指定,舉例來說:
跳脫字元可以是任何的單一字元,除了 16 進位數字的字元、單引號、雙引號、或空白以外。
萬國碼跳脫語法只有在 UTF8 的編碼下才完整支援。當有其他的字元編碼被使用時,就只能使用 ASCII 的範圍(最大值為 \u007F)中的值。4 位數及 6 位數的型式可以用來配對指定 UTF-16 超過 U+FFFF 的字元,即使 6 位數的型式就足以解決這個問題。(當使用配對語法,且字元編碼為 UTF8 時,他們會先被合併成單一字元,然後再編碼成 UTF-8。)
然而,萬國碼的跳脫字串語法,只有在參數 standard_conforming_strings 設定為 on 時有效。這是因為這個語法可能會造成 SQL 指令在編譯時的困擾,造成 SQL 隱碼攻擊(SQL injection) 或其他安全性的問題。如果這個參數設定為 off,那麼這個語法就會被禁止,並且產生錯誤訊息。
內容要使用到跳脫字元的話,就重覆輸入 2 次。
標準的語法用於字串常數的設定很方便的,但如果字串裡有很多單引號或倒斜線,可讀性就很低了,因為它們都必須再連續多一個符號輸入。像這樣的例子,要改善可讀性的話,PostgreSQL 提供了另一個方式,稱作「錢字引號」(dollar quoting),來描述字串常數。錢字引號字串常數包含一個錢字號($),可省略或多個字元所組成的「標籤」,另一個錢字號,組成字川的任何序列文字,再一個錢字號,與起始的錢字引號同樣的標籤,再一個錢字號。舉例來說,這裡有兩個不同使用錢字引號的方式,但都是「Dianne's horse」
注意在錢字引號字串中,單引號的使用就不需要跳脫處理了。實際上,在錢字引號字串中,沒有字元需要跳脫處理:字串內容就原樣輸出。倒斜錢並不特別,就算是錢字號也是,除非它們是引號標籤配對的一部份。
巢狀錢字字串常數是可以的,只要在不同層選擇不同的標籤就好。最常見的用途就是撰寫函數定義。舉例如下:
這裡,「$q$[\t\r\n\v\]$q$」以錢字引號字串輸出就是「[\t\r\n\v\]」,作為 PostgreSQL 的函數內容。但這個字串並不會和外層的 $function$ 配對。對外層的字串而言,它只是被包裏的一部份字元而已。
以錢字符作為標籤(如果有的話)的引號字串和無引號的識別項,遵循相同的規則,除了它無法包含錢字符號以外。標籤是區分大小寫的,所以 $tag$String content$tag$ 是正確的,而 $TAG$String content$tag$ 是不合法的。
錢字引號字串緊接著關鍵字或識別項的話,就必須以空白分隔;否則錢字號的終止符可能會被當作前面識別項的一部份。
錢字引號並不是標準 SQL 的用法,但當撰寫一些複雜字串的時候,會比標準語法更為便利。當字串常數內嵌於另一個常數時,也是很好用的情境,像自訂函數時就時常用到。使用單引號的語法時,前面例子中的每一個倒斜線,需要使用 4 個倒斜線才能表示(原來字串常數時需要雙倒斜線,然後在執行階段時也需要雙倒斜線,一共就是 4 倍)。
位元字串常數看起來就像是一般的字串常數,只是將 B(大小寫皆可)放在引號的前面(不能有空白),例如:B'1001'。而在位元字串當中,只能有 0 或 1 的存在。
另一方面,位元字串常數也可以表示一個 16 進位的值,使用的先導字為 X(大小寫皆可),例如:X'1FF'。這個撰寫方式與使用前段方式,以 4 位數 2 進位表示每一個 16 進位位數,是相同的結果。
這兩種位元字串常數的表達方式,都可以在字串中換行,如同一般的字串常數。錢字引號表示方式不能使用在位元字串常數上。
數值常數可以以下列語法輸入:
這裡的 digits 指的是 0 到 9 的多位數十進位數字。如果有小數點的話,在小數點之前或之後要有數字。在指數標記 e 之前,也必須要有數字。字串中間不能再有其他字元或空白出現。注意,最前面正負號並不是數值常數的一部份,它是屬於運算子的概念。
下面是一些合法數值常數的例子:
42 3.5 4. .001 5e2 1.925e-3
數值常數如果沒有小數點或指數標記的話,預設就會被假定為整數,32 位元以內的為整數型別(interger),否則就會以 64 位元的大整數型別(bigint)來處理。其次就會宣告為數值型別(numeric)。只要包含小數點或指數標記的數值,都會預設使用數值型別。
預設數值常數的資料型別只是整個型別解析演算法的開端而已。在多數的情況下,各種常數會自動被轉換為最貼近內容的適當型別。不過,如果需要的話,你可以強制指定一個資料型別給該常數。舉例來說,你可以強制以實數型別(real 或 float4)來處理該數值:
實際上,在型別轉換上還有一些特殊的情況,留待後續探討。
任意型別的常數,可以使用下列的語法來表示:
字串常數的內容會由型別轉換的程序 type 來處理,其結果就會得到該常數的專屬型別。明定型別轉換可以被省略,如果不會混淆的話(舉例來說,要輸入給特定的表格欄位的話,因為已有型別宣告,就不會混淆),那麼就會自動給定型別。
字串常數可以使用一般 SQL 標準寫法,或是錢字引號寫法。
還可以使用函數式的語法來撰寫:
但並非所有的型別都可以使用這個方式,請參閱 4.2.9 節取得詳細說明。
「::」、CAST()、及函數式語法,也可以用來指定任何表示式在執行中的型別轉換,如同 4.2.9 節中所描述的。要避免語法上的混淆,「type 'string'」這個語法,只能用在指定簡單的文字常數,另一個限制是,不能用於陣列型別。陣列常數的型別指定,請使用 :: 或 CAST() 的語法。
一個運算子最長可以是 NAMEDATALEN - 1(預設為 63 個字元),除了以下的字元之外:
* / <> = ~ ! @ # % ^ & | ` ?
還有一些運算子的限制:
「--」和「/*」都不能出現在運算子裡,因為它們表示註解的開始。
多字元的運算子不能以 + 或 - 結尾,除非名稱裡也包含了下列字元:
~ ! @ # % ^ & | ` ?
舉個例子,@- 可以是合法的運算子,但 *- 就不合法。這個限制是讓 PostgreSQL 解譯 SQL 語法時,可以不需要在不同的標記間使用空白分隔。
當使用非 SQL 標準的運算子時,你通常需要在相隣的運算子間使用空白以免混淆。舉例來說,如果你已經定義了一個左側單元運算子 @,你就不能使用 X*@Y,必須寫成 X* @Y,以確保 PostgreSQL 可以識別為兩個運算子,而不是一個。
有一些字元並不是字母型態,而具有特殊意義,但並非運算子。詳細的說明請參閱相對應的語法說明。本節僅簡要描述這些特殊字元的使用情境。
錢字號($)其後接著數字的話,用來表示函數宣告或預備指令的參數編號。其他的用法還有識別項的一部份,或是錢字引號常數。
小括號(( ))一般用來強調表示式並且優先運算。還有某些情況用於表示某些 SQL 指令的部份的必要性。
中括號([ ])用於組成陣列的各個元素。詳情請參閱 8.15 節有關於陣列的內容。
逗號(,)用於一般語法上的結構需要,來分隔列表中的單元。
分號(;)表示 SQL 指令的結束。它不能出現在指令中的其他位置,除非是在字串常數當中,或是引號識別項。
冒號(:)用在取得陣列的小項。(參閱 8.15 節)在某些 SQL 分支(篏入式 SQL 之類的)中,冒號用來前置變數名稱。
米字號(*)用來表示表格中所有的欄位,或複合性的內容。它也可以用於函數宣告時,不限制固定數量的參數。
頓號(.)用在數值常數之中,也用於區分結構、表格、及欄位名稱。
註解是以連續兩個破折號開頭,一直到行結尾的字串。例如:
另外,C 語言的註解語法也可以使用:
這樣的註解,以「/*」開頭,一直持續到對應的「*/」出現才結束。這樣區塊式的註解可以巢狀使用,所以你可以一次註解掉一堆包含註解的指令。這點是 SQL 的標準,和 C 語言的使用不太一樣的地方。
註解會在進一步的語法分析前被消去,也可以方便地以空白字元替代。
Table 4.2 列出在 PostgreSQL 中,運算子的運算優先權及運算次序。大多數的運算子都是相同的運算優先權,並且是左側運算。這些優先權與次序是撰寫在解譯器的程式當中的。
你有時候需要加上括號,當遇到二元運算子與一元運算子一起出現時。舉個例子:
會被解譯為:
因為解譯器並不知道實際的情況,所以它可能會搞錯。「!」是一個後置運算子,並非中置運算子。在這個例子中,要以想要的方式進行運算的話,你必須要改寫為:
這是為了延展性而需要付出的代價。
Table 4.2. Operator Precedence (highest to lowest)
Operator/Element
Associativity
Description
.
left
table/column name separator
::
left
PostgreSQL-style typecast
[]
left
array element selection
+-
right
unary plus, unary minus
^
left
exponentiation
*/%
left
multiplication, division, modulo
+-
left
addition, subtraction
(any other operator)
left
all other native and user-defined operators
BETWEEN / IN / LIKE / ILIKE / SIMILAR
range containment, set membership, string matching
<>=<=>=<>
comparison operators
IS / ISNULL/ NOTNULL
IS TRUE
,IS FALSE
,IS NULL
,IS DISTINCT FROM
, etc
NOT
right
logical negation
AND
left
logical conjunction
OR
left
logical disjunction
注意,使用與內建運算子同名的自訂運算子,運算優先權的規則也會以原規則適用,如同上面的樣子。舉例來說,如果你定義了一個「+」的運算子,用於自訂的資料型態,那麼它就會和內建的「+」擁有相同的運算優先權,而與你的運算內容無關。
當某個結構操作的運算子用於 OPERATOR 語法之中時,如下所示:
OPERATOR 建構式被用來為任何運算子,取得如 Table 4.2 中所示的預設運算優先權。不論在 OPERATOR() 中指定什麼運算子,都會回傳 true 的結果。
PostgreSQL 在 9.5 之前的運算優先權有一些不同。比較特別的是,比較運算子「<= >= <>」是和一般其他運算子是相同等級的;「IS」先前的優先權較高;而「NOT BETWEEN」和相關的建構式行為不一致,使得在某些情況下,「NOT」和「BETWEEN」的優先權不同。這些規則的改變是為了與 SQL 標準有更好的相容性,減少因為等價轉換的不一致處理所造成的困擾。大多數的情況,這些改變並不需要使用習慣的改變,也不會產生沒有運算子的錯誤,而且都可以透過增加括號來解決。然而,有一些極端的情況可能會在沒有錯誤的情況改變其運算行為。如果你很關心這些變化,很擔心這些無聲的錯誤,你可以打開參數 operator_precedence_warning 來測試你的程式,然後檢查是否有警告被記錄下來。
當你建立了一個複雜的資料庫結構,包含了許多資料表,也設計了許多外部索引鍵、檢視表、觸發事件、函數.....等等。也就是說,其實你建立了一堆物件之間的關連性。舉例來說,資料表的外部索引鍵就與另一個資料表有著參考的關連性。
要維護整個資料庫結構的完整性,PostgreSQL 得確保你不能在有關連性的情況下,隨意刪去物件。舉例來說,企圖刪去在 5.3.5 節中,我們所使用過的產品資料表,而訂單資料表與其有相依的關連性,那就會產生如下的錯誤訊息:
這個錯誤訊息包含了很有用的指引:如果你不想要一個個處理其相依關連性,那可以一次刪去他們:
如此所有相依的物件就會被刪除了,所有相互依存的物件都會,是遞迴式的處理流程。在這個例子中,它不會移除訂單資料表,只會移除外部索引鍵的限制條件,因為沒有其他物件與該外部索引鍵相依。(如果你要確認 DROP ... CASCADE 會處理哪些物件,你可以用 DETAIL 取代 CASCADE,就會輸出其相依的物件。)
幾乎所有 PostgreSQL 的 DROP 指令都支援 CASCADE 的用法。當然,有些自然的關連性是和物件型別有關。你也可以使用 RESTRICT 來取代 CASCADE 的位置,以強制以預設的行為來處理,也就是絕對不會刪去其他相關的物件。
根據 SQL 標準,不論是 RESTRICT 或 CASCADE,都必須要在 DROP 指令中明確表示,但沒有任何一套資料庫系統真的這樣設計。不過,都會內定預設行為是 RESTRICT 或 CASCADE,每個資料庫不同。
如果 DROP 指令列出了多個物件,CASCADE 只有在這些物件之外還有相依性時才會需要。舉個例子,當執行「DROP TABLE tab1, tab2」時,即使 tab1 與 tab2 之間有外部索引鍵的相依關係,而沒有指定 CASCADE,這個操作也會完成。
對於使用者自訂的函數來說,PostgreSQL 會引用函數的外顯屬性來判斷其相依性,例如函數的參數或輸出型態,但函數內部執行的相依關係就無法追蹤了。舉個列子:
(參閱 37.4 節,瞭解 SQL 語言的函數。)PostgreSQL 會知道 get_color_note 函數相依於 rainbow 資料型別:也就是刪去該資料型別時,也會強制要刪去該函數,因為它的參數將不再合法。但 PostgreSQL 就無法發現 get_color_note 和 my_colors 之間的關連性,當該資料表被移除時,此函數並不會跟著被移除。這種情況有好有壞,函數基本上還是合法的,即使內含的資料表不存在的話,頂多就是執行會出錯就是了,只要再建立該名稱的資料表就可以讓這個函數重新正常運作。
資料表在建立的時候,並不包含任何資料。以各種方式使用資料庫之前,要做的第一件事就是新增資料。概念上,資料是一次新增一列。當然你也可以新增多列,但就沒有辦法新增少於一列。 即使只知道某些欄位的值,也必須建立一個完整的資料列。
要建立新的資料列,請使用 INSERT 指令。該命令需要資料表的名稱和各欄位的資料內容。例如,來看看第 5 章中的產品資料表:
新增資料列的指令可能如下所示:
資料內容按資料表表中欄位的順序列出,以逗號分隔。通常,資料內容會是文字(常數),但運算表示式也是允許的。
上面的語法有缺點,就是你需要知道資料表中欄位的順序。為了避免這種情況,您可以明確地列出欄位。例如,以下兩個命令與上面的命令具有相同的效果:
許多用戶認為總是列出欄位名稱是一個很好的習慣。
如果你並沒有所有欄位的內容,則可以省略其中一些欄位。在這種情況下,那些欄位將會以預設值代入。如下所示:
第二種形式是屬於 PostgreSQL 延伸寫法。 從左邊開始的欄位填入所給定的內容,其餘的欄位則使用預設值。
為了清楚起見,你也可以明確地指定個別欄位或整個資料列都使用預設值:
您可以在一個命令中新增多個資料列:
也可以以查詢的結果新增(可能沒有資料,一個資料列或多個資料列):
這包含完整 SQL 查詢機制(第 7 章)用於計算需要新增的資料列。
同時要新增大量資料時,請考慮使用 COPY 指令。它不像 INSERT 指令那麼靈活,但是效率更高。有關提高批次新增資料效率的更多資訊,請參閱第 14.4 節。
PostgreSQL 實作了資料表的繼承方式,對於資料庫設計人員來說,將會是很好用的功能。(SQL:1999 之後定義了型別繼承的功能,但和這裡所介紹的方向有許多不同。)
我們直接以一個例子作為開始:假設我們嘗試建立「城市(city)」的資料模型。每一個州(state)都會有許多城市(city),但只會有一個首都(capital)。我們想要很快地可以找到某個州的首都。這件事我們需要建立兩個資料表,一個存放首都,而另一個記載非首都的城市。只是,當我們想要取得的是所有城市,不論是否為首都,似乎會有些麻煩?這時候繼承功能就可以幫助我們解決這個問題。我們可以定義一個資料表 capitals,它是由資料表 cities 繼承而來:
在這個例子中,資料表 capitals 會繼承父資料表 cities 的所有欄位。只是 capitals 會多一個欄位 state,表示它是哪個州的首都。
在 PostgreSQL 裡,一個資料表可以繼承多個資料表,而一個查詢可以引用該資料表裡的所有資料列或在其所屬的資料表的資料列,後者的行為是預設的。舉個例子,下面的查詢可以列出所有海沷在 500 英呎以上的城市名稱,州的首都也包含在內:
使用 2.1 節中的範例資料,將會回傳:
換句話說,下面的查詢就會查出非首都且海沷超過 500 英呎以上的城市:
這裡「ONLY」關鍵字指的是查詢只需要包含資料表 cities 就好,而不是任何繼承 cities 的資料表都包含在內。我們先前介紹過的指令:SELECT、UPDATE、和 DELETE,都可以使用 ONLY 關鍵字。
你也可以在資料表名稱後面加上「*」,明確指出繼承的資料表都需要包含在內:
注意這個「*」並不是必要的,因為這個行為本來就是預設的。這個語法用於相容舊的版本,有些版本的預設行為可能不太一樣。
在某些例子裡,也許你會希望知道哪些資料列來自於哪個資料表。有一個系統欄位稱作 tableoid,每一個資料表都會有,而它可告訴你資料列的來源:
這將會回傳:
(如果你嘗試重覆執行這個例子,你可能會得到不同的 OID 值。)藉由和資料表 pg_class 交叉查詢,你可以看到實際的資料表名稱:
將會回傳:
另一個可以得到相同結果的方式是,使用 regclass 別名型別,這個型別會將 OID 轉換成名稱輸出:
在使用 INSERT 或 COPY 指令時,繼承並不會自動轉存資料。在我們的例子中,下面的 INSERT 指令將會失敗:
我們可能會希望資料以某種方式轉送到資料表 capitals 中,但這不會發生:INSERT 指令永遠只會將資料插入到指定的資料表中。在某些情況下,如果設定了存取規則(第 40 章)的話,那有可能做到類似的效果。然而,在這個例子下是沒有辦法執行的,因為資料表 cities 中並沒有一個欄位稱作 state,所以這個指令將會被拒絕執行,如果沒有其他規則被設定的話。
所有限制條件的檢查,還有非空值的限制,都會自動從父資料表繼承下來,除非特別使用 NO INHERIT 子句來設定拋棄繼承。而其他型態的限制條件(唯一性、主鍵、外部鍵)都不會自動繼承。
一個資料表也可以繼承超過一個資料表,也就是說,它會擁有這些資料表全部的欄位,然後再加上自己所宣告的欄位。如果父資料表有相同名稱的欄位的話,或是父資料表和子資料表有同名的欄位,那麼這些欄位會被合併,它們會被合併為一個欄位。合併的時候,他們的資料型別必須要一致,否則會產生錯誤。被繼承的限制條件和無空值的限制也會用類似的方式合併。舉個例子來說,如果要合併的欄位中,任何一個欄位有 not-null 的設定的話,那麼合併後的欄位就會被設定為 not-null。如果有同名的限制條件要被合併,但他們的內容不相同的話,那麼合併也會失敗。
資料表的繼承一般來說是在子資料表建立時進行的,也就是在 CREATE TABLE 中使用 INHERITES 子句。然而,資料表也可以在 ALTER TABLE 中使用 INHERIT 子句來新增新的父資料表。要進行這個動作,新的子資料表必須已經包含所有父資料表的欄位—相同的欄位名稱及資料型別。還有在 ALTER TABLE 時加入 INHERIT 子句來移除某個欄位的繼承。動態地新增或移除繼承欄位通常是在應用分割表格(table partitioning)時特別好用(請參閱 5.10 節)。
還有一個方便的方式去建立一個相容於之後繼承的資料表,就是在 CREATE TABLE 中使用 LIKE 子句。這個方式會建立一個新的資料表,其欄位和另一個資料表完全相同。如果有任何 CHECK 子句的限制條件的話,就應該在 LIKE 子句中加入 INCLUDING CONSTRAINTS 選項,這樣就會和父資料表完全相容了。
父資料表無法在子資料表仍然存在時被移除。子資料表的欄位和限制條件也不能被移除,如果它們是由其他資料表繼承而來的話。如果你想要移除某個資料表,包含其相關的物件的話,一個簡單的方式就是在移除時加上 CASCADE 選項(請參閱 5.13 節)。
ALTER TABLE 將會讓欄位型態和限制條件的改變,衍生至繼承它的資料表之中。一樣地,移除某個欄位,如果它有被其他資料表繼承的話,那麼就必須要加上 CASCADE 選項才行。ALTER TABLE 會遵循和 CREATE TABLE 一樣的規則,決定重覆的欄位要合併還是拒絕。
指令的繼承權限是依父資料表的權限。舉個例子,當你存取資料表 cities 時,在 cities 上給予 UPDATE 的權限,同時也隱含了賦予 capitals 更新資料的權限。這考量到這些資料也會出現在父資料表,但如果你沒有特別給予 capitals 權限的話,你還是無法直接存取 capitals。類似的情況也會發生在資料列的安全原則(5.7 節),在繼承查詢時,同樣是參考父資料表的安全原則。而子資料表額外的安全原則,只在直接查詢該資料表時有效,同時任何父資料表的安全原則會失效。
外部資料表(5.11 節)也可以是繼承的一部份,父資料表或子資料表,就如同一般的資料表一樣。只是,如果整個繼承結構中,有任何外部資料不支援的操作的話,那麼整個繼承結構就都不支援。
注意,並非所有的 SQL 指令都可以在繼承結構中執行。一般常用的資料查詢,資料更新,或結構調整(像是 SELECT、UPDATE、DELETE,還有多數 ALTER TABLE 的功能,但不包括 INSERT 或 ALTER TABLE ...... RENAME),基本上預設都是包含子資料表,也支援使用 ONLY 指示字來排除子資料表。如果是資料庫維護或調教的指令,如 REINDEX、VACUUM,一般就只支援特定且實體的資料表,就不會在繼承結構中衍生其他的動作。這些個別指令相關的行為,請參閱 SQL Commands 內的說明。
繼承功能比較嚴格的限制是索引(包含唯一性索引),還有外部鍵的限制條件,都只能用在單一資料表,而不會衍生至他們的子資料表中。對外部鍵來說,無論引用資料表或是參考資料表的情況都一樣。下面是一些例子說明:
如果我們宣告 cities.name 具備唯一性或是主鍵,這不會限制到 capitals 中有重覆的項目。而這些重覆的資料列就會出現在 cities 的查詢結果中。事實上,預設的 capitals 就沒有唯一性的限制,所以就可能有多個資料列記載相同的名稱。你可以在 capitals 中也加入唯一性索引,但這也無法避免 capitals 和 cities 中有重覆的項目。
同樣地,如果我們指定 cities.name 以外部鍵的方式,參考另一個資料表,而這個外部鍵也不會衍生到 capitals 中。這種情況你就必須在 capitals 中也以 REFERENCES 設定同樣外部鍵的引用。
如果有另一個資料表的欄位設定了 REFERENCES cities(name) 就會允許其他的資料表包含城市名稱,但就沒有首都名稱。在這個情況下,沒有好的解決辦法。
這些缺點可能會在後續的版本中被修正,但在此時此刻,當你需要使用繼承功能讓你的應用設計更好用時,你就必須要同時考慮這些限制。
檢索過程或從資料庫檢索資料的命令稱之為查詢。在 SQL 中,SELECT 命令用於進行條件查詢。 SELECT 指令的一般語法是:
以下各節介紹了資料列表(select list),資料表和排序規則的詳細資訊。由於 WITH 查詢是高級功能,因此最後再介紹。
一種簡單的查詢形式如下:
假設有一個名稱為 table1 的資料表,該指令會將取出 table1 中的所有資料表和所有用戶定義的欄位。(檢索的方法取決於用戶端的應用程序,例如,psql 程序將在屏幕上顯示一個 ASCII-art 表格,而用戶端的程式函式庫將提供從查詢結果中提取單一值的功能。選擇資料列表定義「*」表示由資料表表示式所產生的所有欄位。篩選列表可以是可用欄位的子集或使用欄位進行計算。例如,如果 table1 具有名稱為 a,b 和 c(也許是其他)的欄位,則可以進行以下查詢:
(假設 b 和 c 是數字型別)。更多細節詳見 。
FROM table1是一種簡單的資料表表示式:它只讀取一個資料表。一般來說,資料表表示式可以是一般的資料表,交叉查詢和子查詢的複雜結構。但是,你也可以完全省略資料表表示式,並使用 SELECT 指令作為計算機:
使用資料列表中的表達式產生變動的結果,是更為常用的方式。例如,你可以這樣呼叫一個函數:
A table expression computes a table. The table expression contains a FROM
clause that is optionally followed by WHERE
, GROUP BY
, and HAVING
clauses. Trivial table expressions simply refer to a table on disk, a so-called base table, but more complex expressions can be used to modify or combine base tables in various ways.
The optional WHERE
, GROUP BY
, and HAVING
clauses in the table expression specify a pipeline of successive transformations performed on the table derived in the FROM
clause. All these transformations produce a virtual table that provides the rows that are passed to the select list to compute the output rows of the query.
FROM
ClauseThe derives a table from one or more other tables given in a comma-separated table reference list.
A table reference can be a table name (possibly schema-qualified), or a derived table such as a subquery, a JOIN
construct, or complex combinations of these. If more than one table reference is listed in the FROM
clause, the tables are cross-joined (that is, the Cartesian product of their rows is formed; see below). The result of the FROM
list is an intermediate virtual table that can then be subject to transformations by the WHERE
, GROUP BY
, and HAVING
clauses and is finally the result of the overall table expression.
When a table reference names a table that is the parent of a table inheritance hierarchy, the table reference produces rows of not only that table but all of its descendant tables, unless the key word ONLY
precedes the table name. However, the reference produces only the columns that appear in the named table — any columns added in subtables are ignored.
Instead of writing ONLY
before the table name, you can write *
after the table name to explicitly specify that descendant tables are included. There is no real reason to use this syntax any more, because searching descendant tables is now always the default behavior. However, it is supported for compatibility with older releases.
7.2.1.1. Joined Tables
A joined table is a table derived from two other (real or derived) tables according to the rules of the particular join type. Inner, outer, and cross-joins are available. The general syntax of a joined table is
Joins of all types can be chained together, or nested: either or both T1
and T2
can be joined tables. Parentheses can be used around JOIN
clauses to control the join order. In the absence of parentheses, JOIN
clauses nest left-to-right.
Join TypesCross join
For every possible combination of rows from T1
and T2
(i.e., a Cartesian product), the joined table will contain a row consisting of all columns in T1
followed by all columns in T2
. If the tables have N and M rows respectively, the joined table will have N * M rows.
FROM
T1
CROSS JOIN T2
is equivalent to FROM
T1
INNER JOIN T2
ON TRUE (see below). It is also equivalent to FROM
T1
, T2
.
This latter equivalence does not hold exactly when more than two tables appear, because JOIN
binds more tightly than comma. For example FROM
T1
CROSS JOIN T2
INNER JOIN T3
ON condition
is not the same as FROM
T1
, T2
INNER JOIN T3
ON condition
because the condition
can referenceT1
in the first case but not the second.Qualified joins
The words INNER
and OUTER
are optional in all forms. INNER
is the default; LEFT
, RIGHT
, and FULL
imply an outer join.
The join condition is specified in the ON
or USING
clause, or implicitly by the word NATURAL
. The join condition determines which rows from the two source tables are considered to “match”, as explained in detail below.
The possible types of qualified join are:INNER JOIN
For each row R1 of T1, the joined table has a row for each row in T2 that satisfies the join condition with R1.LEFT OUTER JOIN
First, an inner join is performed. Then, for each row in T1 that does not satisfy the join condition with any row in T2, a joined row is added with null values in columns of T2. Thus, the joined table always has at least one row for each row in T1.RIGHT OUTER JOIN
First, an inner join is performed. Then, for each row in T2 that does not satisfy the join condition with any row in T1, a joined row is added with null values in columns of T1. This is the converse of a left join: the result table will always have a row for each row in T2.FULL OUTER JOIN
First, an inner join is performed. Then, for each row in T1 that does not satisfy the join condition with any row in T2, a joined row is added with null values in columns of T2. Also, for each row of T2 that does not satisfy the join condition with any row in T1, a joined row with null values in the columns of T1 is added.
The ON
clause is the most general kind of join condition: it takes a Boolean value expression of the same kind as is used in a WHERE
clause. A pair of rows from T1
and T2
match if the ON
expression evaluates to true.
The USING
clause is a shorthand that allows you to take advantage of the specific situation where both sides of the join use the same name for the joining column(s). It takes a comma-separated list of the shared column names and forms a join condition that includes an equality comparison for each one. For example, joining T1
and T2
with USING (a, b)
produces the join condition ON
T1
.a = T2
.a AND T1
.b = T2
.b.
Furthermore, the output of JOIN USING
suppresses redundant columns: there is no need to print both of the matched columns, since they must have equal values. While JOIN ON
produces all columns from T1
followed by all columns from T2
, JOIN USING
produces one output column for each of the listed column pairs (in the listed order), followed by any remaining columns from T1
, followed by any remaining columns from T2
.
Finally, NATURAL
is a shorthand form of USING
: it forms a USING
list consisting of all column names that appear in both input tables. As with USING
, these columns appear only once in the output table. If there are no common column names, NATURAL JOIN
behaves like JOIN ... ON TRUE
, producing a cross-product join.
USING
is reasonably safe from column changes in the joined relations since only the listed columns are combined. NATURAL
is considerably more risky since any schema changes to either relation that cause a new matching column name to be present will cause the join to combine that new column as well.
To put this together, assume we have tables t1
:
and t2
:
then we get the following results for the various joins:
The join condition specified with ON
can also contain conditions that do not relate directly to the join. This can prove useful for some queries but needs to be thought out carefully. For example:
Notice that placing the restriction in the WHERE
clause produces a different result:
This is because a restriction placed in the ON
clause is processed before the join, while a restriction placed in the WHERE
clause is processed after the join. That does not matter with inner joins, but it matters a lot with outer joins.
7.2.1.2. Table and Column Aliases
A temporary name can be given to tables and complex table references to be used for references to the derived table in the rest of the query. This is called a table alias.
To create a table alias, write
or
The AS
key word is optional noise. alias
can be any identifier.
A typical application of table aliases is to assign short identifiers to long table names to keep the join clauses readable. For example:
The alias becomes the new name of the table reference so far as the current query is concerned — it is not allowed to refer to the table by the original name elsewhere in the query. Thus, this is not valid:
Table aliases are mainly for notational convenience, but it is necessary to use them when joining a table to itself, e.g.:
Parentheses are used to resolve ambiguities. In the following example, the first statement assigns the alias b
to the second instance of my_table
, but the second statement assigns the alias to the result of the join:
Another form of table aliasing gives temporary names to the columns of the table, as well as the table itself:
If fewer column aliases are specified than the actual table has columns, the remaining columns are not renamed. This syntax is especially useful for self-joins or subqueries.
When an alias is applied to the output of a JOIN
clause, the alias hides the original name(s) within the JOIN
. For example:
is valid SQL, but:
is not valid; the table alias a
is not visible outside the alias c
.
7.2.1.3. Subqueries
This example is equivalent to FROM table1 AS alias_name
. More interesting cases, which cannot be reduced to a plain join, arise when the subquery involves grouping or aggregation.
A subquery can also be a VALUES
list:
7.2.1.4. Table Functions
Table functions are functions that produce a set of rows, made up of either base data types (scalar types) or composite data types (table rows). They are used like a table, view, or subquery in the FROM
clause of a query. Columns returned by table functions can be included in SELECT
, JOIN
, or WHERE
clauses in the same manner as columns of a table, view, or subquery.
Table functions may also be combined using the ROWS FROM
syntax, with the results returned in parallel columns; the number of result rows in this case is that of the largest function result, with smaller results padded with null values to match.
If the WITH ORDINALITY
clause is specified, an additional column of type bigint
will be added to the function result columns. This column numbers the rows of the function result set, starting from 1. (This is a generalization of the SQL-standard syntax for UNNEST ... WITH ORDINALITY
.) By default, the ordinal column is called ordinality
, but a different column name can be assigned to it using an AS
clause.
If no table_alias
is specified, the function name is used as the table name; in the case of a ROWS FROM()
construct, the first function's name is used.
If column aliases are not supplied, then for a function returning a base data type, the column name is also the same as the function name. For a function returning a composite type, the result columns get the names of the individual attributes of the type.
Some examples:
In some cases it is useful to define table functions that can return different column sets depending on how they are invoked. To support this, the table function can be declared as returning the pseudo-type record
. When such a function is used in a query, the expected row structure must be specified in the query itself, so that the system can know how to parse and plan the query. This syntax looks like:
When not using the ROWS FROM()
syntax, the column_definition
list replaces the column alias list that could otherwise be attached to the FROM
item; the names in the column definitions serve as column aliases. When using the ROWS FROM()
syntax, a column_definition
list can be attached to each member function separately; or if there is only one member function and no WITH ORDINALITY
clause, a column_definition
list can be written in place of a column alias list following ROWS FROM()
.
Consider this example:
7.2.1.5. LATERAL Subqueries
Subqueries appearing in FROM
can be preceded by the key word LATERAL
. This allows them to reference columns provided by preceding FROM
items. (Without LATERAL
, each subquery is evaluated independently and so cannot cross-reference any other FROM
item.)
Table functions appearing in FROM
can also be preceded by the key word LATERAL
, but for functions the key word is optional; the function's arguments can contain references to columns provided by preceding FROM
items in any case.
A LATERAL
item can appear at top level in the FROM
list, or within a JOIN
tree. In the latter case it can also refer to any items that are on the left-hand side of a JOIN
that it is on the right-hand side of.
When a FROM
item contains LATERAL
cross-references, evaluation proceeds as follows: for each row of the FROM
item providing the cross-referenced column(s), or set of rows of multiple FROM
items providing the columns, the LATERAL
item is evaluated using that row or row set's values of the columns. The resulting row(s) are joined as usual with the rows they were computed from. This is repeated for each row or set of rows from the column source table(s).
A trivial example of LATERAL
is
This is not especially useful since it has exactly the same result as the more conventional
LATERAL
is primarily useful when the cross-referenced column is necessary for computing the row(s) to be joined. A common application is providing an argument value for a set-returning function. For example, supposing that vertices(polygon)
returns the set of vertices of a polygon, we could identify close-together vertices of polygons stored in a table with:
This query could also be written
or in several other equivalent formulations. (As already mentioned, the LATERAL
key word is unnecessary in this example, but we use it for clarity.)
It is often particularly handy to LEFT JOIN
to a LATERAL
subquery, so that source rows will appear in the result even if the LATERAL
subquery produces no rows for them. For example, if get_product_names()
returns the names of products made by a manufacturer, but some manufacturers in our table currently produce no products, we could find out which ones those are like this:
WHERE
ClauseAfter the processing of the FROM
clause is done, each row of the derived virtual table is checked against the search condition. If the result of the condition is true, the row is kept in the output table, otherwise (i.e., if the result is false or null) it is discarded. The search condition typically references at least one column of the table generated in the FROM
clause; this is not required, but otherwise the WHERE
clause will be fairly useless.
The join condition of an inner join can be written either in the WHERE
clause or in the JOIN
clause. For example, these table expressions are equivalent:
and:
or perhaps even:
Which one of these you use is mainly a matter of style. The JOIN
syntax in the FROM
clause is probably not as portable to other SQL database management systems, even though it is in the SQL standard. For outer joins there is no choice: they must be done in the FROM
clause. The ON
or USING
clause of an outer join is not equivalent to a WHERE
condition, because it results in the addition of rows (for unmatched input rows) as well as the removal of rows in the final result.
Here are some examples of WHERE
clauses:
fdt
is the table derived in the FROM
clause. Rows that do not meet the search condition of the WHERE
clause are eliminated from fdt
. Notice the use of scalar subqueries as value expressions. Just like any other query, the subqueries can employ complex table expressions. Notice also how fdt
is referenced in the subqueries. Qualifying c1
as fdt.c1
is only necessary if c1
is also the name of a column in the derived input table of the subquery. But qualifying the column name adds clarity even when it is not needed. This example shows how the column naming scope of an outer query extends into its inner queries.
GROUP BY
and HAVING
ClausesAfter passing the WHERE
filter, the derived input table might be subject to grouping, using the GROUP BY
clause, and elimination of group rows using the HAVING
clause.
In the second query, we could not have written SELECT * FROM test1 GROUP BY x
, because there is no single value for the column y
that could be associated with each group. The grouped-by columns can be referenced in the select list since they have a single value in each group.
In general, if a table is grouped, columns that are not listed in GROUP BY
cannot be referenced except in aggregate expressions. An example with aggregate expressions is:
Here is another example: it calculates the total sales for each product (rather than the total sales of all products):
In this example, the columns product_id
, p.name
, and p.price
must be in the GROUP BY
clause since they are referenced in the query select list (but see below). The columns.units
does not have to be in the GROUP BY
list since it is only used in an aggregate expression (sum(...)
), which represents the sales of a product. For each product, the query returns a summary row about all sales of the product.
If the products table is set up so that, say, product_id
is the primary key, then it would be enough to group by product_id
in the above example, since name and price would be functionally dependent on the product ID, and so there would be no ambiguity about which name and price value to return for each product ID group.
In strict SQL, GROUP BY
can only group by columns of the source table but PostgreSQL extends this to also allow GROUP BY
to group by columns in the select list. Grouping by value expressions instead of simple column names is also allowed.
If a table has been grouped using GROUP BY
, but only certain groups are of interest, the HAVING
clause can be used, much like a WHERE
clause, to eliminate groups from the result. The syntax is:
Expressions in the HAVING
clause can refer both to grouped expressions and to ungrouped expressions (which necessarily involve an aggregate function).
Example:
Again, a more realistic example:
In the example above, the WHERE
clause is selecting rows by a column that is not grouped (the expression is only true for sales during the last four weeks), while the HAVING
clause restricts the output to groups with total gross sales over 5000. Note that the aggregate expressions do not necessarily need to be the same in all parts of the query.
If a query contains aggregate function calls, but no GROUP BY
clause, grouping still occurs: the result is a single group row (or perhaps no rows at all, if the single row is then eliminated by HAVING
). The same is true if it contains a HAVING
clause, even without any aggregate function calls or GROUP BY
clause.
GROUPING SETS
, CUBE
, and ROLLUP
More complex grouping operations than those described above are possible using the concept of grouping sets. The data selected by the FROM
and WHERE
clauses is grouped separately by each specified grouping set, aggregates computed for each group just as for simple GROUP BY
clauses, and then the results returned. For example:
Each sublist of GROUPING SETS
may specify zero or more columns or expressions and is interpreted the same way as though it were directly in the GROUP BY
clause. An empty grouping set means that all rows are aggregated down to a single group (which is output even if no input rows were present), as described above for the case of aggregate functions with no GROUP BY
clause.
A shorthand notation is provided for specifying two common types of grouping set. A clause of the form
represents the given list of expressions and all prefixes of the list including the empty list; thus it is equivalent to
This is commonly used for analysis over hierarchical data; e.g. total salary by department, division, and company-wide total.
A clause of the form
represents the given list and all of its possible subsets (i.e. the power set). Thus
is equivalent to
The individual elements of a CUBE
or ROLLUP
clause may be either individual expressions, or sublists of elements in parentheses. In the latter case, the sublists are treated as single units for the purposes of generating the individual grouping sets. For example:
is equivalent to
and
is equivalent to
The CUBE
and ROLLUP
constructs can be used either directly in the GROUP BY
clause, or nested inside a GROUPING SETS
clause. If one GROUPING SETS
clause is nested inside another, the effect is the same as if all the elements of the inner clause had been written directly in the outer clause.
If multiple grouping items are specified in a single GROUP BY
clause, then the final list of grouping sets is the cross product of the individual items. For example:
is equivalent to
When multiple window functions are used, all the window functions having syntactically equivalent PARTITION BY
and ORDER BY
clauses in their window definitions are guaranteed to be evaluated in a single pass over the data. Therefore they will see the same sort ordering, even if the ORDER BY
does not uniquely determine an ordering. However, no guarantees are made about the evaluation of functions having different PARTITION BY
or ORDER BY
specifications. (In such cases a sort step is typically required between the passes of window function evaluations, and the sort is not guaranteed to preserve ordering of rows that its ORDER BY
sees as equivalent.)
Currently, window functions always require presorted data, and so the query output will be ordered according to one or another of the window functions' PARTITION BY
/ORDER BY
clauses. It is not recommended to rely on this, however. Use an explicit top-level ORDER BY
clause if you want to be sure the results are sorted in a particular way.
Additionally, an alias is required if the table reference is a subquery (see ).
Subqueries specifying a derived table must be enclosed in parentheses and must be assigned a table alias name (as in ). For example:
Again, a table alias is required. Assigning alias names to the columns of the VALUES
list is optional, but is good practice. For more information see .
The special table function UNNEST
may be called with any number of array parameters, and it returns a corresponding number of columns, as if UNNEST
() had been called on each parameter separately and combined using the ROWS FROM
construct.
The function (part of the module) executes a remote query. It is declared to return record
since it might be used for any kind of query. The actual column set must be specified in the calling query so that the parser knows, for example, what *
should expand to.
The syntax of the is
where search_condition
is any value expression (see ) that returns a value of type boolean
.
The is used to group together those rows in a table that have the same values in all the columns listed. The order in which the columns are listed does not matter. The effect is to combine each set of rows having common values into one group row that represents all rows in the group. This is done to eliminate redundancy in the output and/or compute aggregates that apply to these groups. For instance:
Here sum
is an aggregate function that computes a single value over the entire group. More information about the available aggregate functions can be found in .
Grouping without aggregate expressions effectively calculates the set of distinct values in a column. This can also be achieved using the DISTINCT
clause (see ).
References to the grouping columns or expressions are replaced by null values in result rows for grouping sets in which those columns do not appear. To distinguish which grouping a particular output row resulted from, see .
The construct (a, b)
is normally recognized in expressions as a . Within the GROUP BY
clause, this does not apply at the top levels of expressions, and (a, b)
is parsed as a list of expressions as described above. If for some reason you need a row constructor in a grouping expression, use ROW(a, b)
.
If the query contains any window functions (see , and ), these functions are evaluated after any grouping, aggregation, and HAVING
filtering is performed. That is, if the query uses any aggregates, GROUP BY
, or HAVING
, then the rows seen by the window functions are the group rows instead of the original table rows from FROM
/WHERE
.
版本:11
PostgreSQL 提供了三種不同的特徵比對方法:傳統的 SQL LIKE 運算子,最新的 SIMILAR TO 運算子(於 SQL:1999 中加入)和 POSIX 樣式的正規表示式。除了基本的「這個字串符合這個樣式嗎?」運算子之外,還可以使用函數來提取或替換符合的子字串,以及在配對的位置拆分字串。
提醒 如果您的特徵比對需求超出此範圍,請考慮在 Perl 或 Tcl 中撰寫使用者定義的函數。
雖然大多數正規表示式搜尋可以非常快速地執行,但是完成正規表示式需要花費大量的時間和記憶體來處理。要特別注意從各種來源接受正規表示式的搜尋方式。如果必須這樣做,建議強制限制執行語句執行時間。
使用 SIMILAR TO 方式的搜尋具有相同的安全隱憂,因為 SIMILAR TO 提供了許多與 POSIX 樣式的正規表示式相同功能。
LIKE 搜尋比其他兩個選項要簡單得多,在使用可能惡意的來源時更安全。
LIKE
The LIKE
expression returns true if the string
matches the supplied pattern
. (As expected, the NOT LIKE
expression returns false if LIKE
returns true, and vice versa. An equivalent expression is NOT (
string
LIKE pattern
).)
If pattern
does not contain percent signs or underscores, then the pattern only represents the string itself; in that case LIKE
acts like the equals operator. An underscore (_
) in pattern
stands for (matches) any single character; a percent sign (%
) matches any sequence of zero or more characters.
Some examples:
LIKE
pattern matching always covers the entire string. Therefore, if it's desired to match a sequence anywhere within a string, the pattern must start and end with a percent sign.
To match a literal underscore or percent sign without matching other characters, the respective character in pattern
must be preceded by the escape character. The default escape character is the backslash but a different one can be selected by using the ESCAPE
clause. To match the escape character itself, write two escape characters.
If you have standard_conforming_strings turned off, any backslashes you write in literal string constants will need to be doubled. See Section 4.1.2.1 for more information.
It's also possible to select no escape character by writing ESCAPE ''
. This effectively disables the escape mechanism, which makes it impossible to turn off the special meaning of underscore and percent signs in the pattern.
The key word ILIKE
can be used instead of LIKE
to make the match case-insensitive according to the active locale. This is not in the SQL standard but is a PostgreSQL extension.
The operator ~~
is equivalent to LIKE
, and ~~*
corresponds to ILIKE
. There are also !~~
and !~~*
operators that represent NOT LIKE
and NOT ILIKE
, respectively. All of these operators are PostgreSQL-specific.
There is also the prefix operator ^@
and corresponding starts_with
function which covers cases when only searching by beginning of the string is needed.
SIMILAR TO
Regular ExpressionsThe SIMILAR TO
operator returns true or false depending on whether its pattern matches the given string. It is similar to LIKE
, except that it interprets the pattern using the SQL standard's definition of a regular expression. SQL regular expressions are a curious cross between LIKE
notation and common regular expression notation.
Like LIKE
, the SIMILAR TO
operator succeeds only if its pattern matches the entire string; this is unlike common regular expression behavior where the pattern can match any part of the string. Also like LIKE
, SIMILAR TO
uses _
and %
as wildcard characters denoting any single character and any string, respectively (these are comparable to .
and .*
in POSIX regular expressions).
In addition to these facilities borrowed from LIKE
, SIMILAR TO
supports these pattern-matching metacharacters borrowed from POSIX regular expressions:
|
denotes alternation (either of two alternatives).
*
denotes repetition of the previous item zero or more times.
+
denotes repetition of the previous item one or more times.
?
denotes repetition of the previous item zero or one time.
{
m
}
denotes repetition of the previous item exactly m
times.
{
m
,}
denotes repetition of the previous item m
or more times.
{
m
,
n
}
denotes repetition of the previous item at least m
and not more than n
times.
Parentheses ()
can be used to group items into a single logical item.
A bracket expression [...]
specifies a character class, just as in POSIX regular expressions.
Notice that the period (.
) is not a metacharacter for SIMILAR TO
.
As with LIKE
, a backslash disables the special meaning of any of these metacharacters; or a different escape character can be specified with ESCAPE
.
Some examples:
The substring
function with three parameters, substring(
string
from pattern
for escape-character
), provides extraction of a substring that matches an SQL regular expression pattern. As with SIMILAR TO
, the specified pattern must match the entire data string, or else the function fails and returns null. To indicate the part of the pattern that should be returned on success, the pattern must contain two occurrences of the escape character followed by a double quote ("
). The text matching the portion of the pattern between these markers is returned.
Some examples, with #"
delimiting the return string:
Table 9.14 lists the available operators for pattern matching using POSIX regular expressions.
Operator
Description
Example
~
Matches regular expression, case sensitive
'thomas' ~ '.*thomas.*'
~*
Matches regular expression, case insensitive
'thomas' ~* '.*Thomas.*'
!~
Does not match regular expression, case sensitive
'thomas' !~ '.*Thomas.*'
!~*
Does not match regular expression, case insensitive
'thomas' !~* '.*vadim.*'
POSIX regular expressions provide a more powerful means for pattern matching than the LIKE
and SIMILAR TO
operators. Many Unix tools such as egrep
, sed
, or awk
use a pattern matching language that is similar to the one described here.
A regular expression is a character sequence that is an abbreviated definition of a set of strings (a regular set). A string is said to match a regular expression if it is a member of the regular set described by the regular expression. As with LIKE
, pattern characters match string characters exactly unless they are special characters in the regular expression language — but regular expressions use different special characters than LIKE
does. Unlike LIKE
patterns, a regular expression is allowed to match anywhere within a string, unless the regular expression is explicitly anchored to the beginning or end of the string.
Some examples:
The POSIX pattern language is described in much greater detail below.
The substring
function with two parameters, substring(
string
from pattern
), provides extraction of a substring that matches a POSIX regular expression pattern. It returns null if there is no match, otherwise the portion of the text that matched the pattern. But if the pattern contains any parentheses, the portion of the text that matched the first parenthesized subexpression (the one whose left parenthesis comes first) is returned. You can put parentheses around the whole expression if you want to use parentheses within it without triggering this exception. If you need parentheses in the pattern before the subexpression you want to extract, see the non-capturing parentheses described below.
Some examples:
The regexp_replace
function provides substitution of new text for substrings that match POSIX regular expression patterns. It has the syntax regexp_replace
(source
, pattern
, replacement
[, flags
]). The source
string is returned unchanged if there is no match to the pattern
. If there is a match, the source
string is returned with the replacement
string substituted for the matching substring. The replacement
string can contain \
n
, where n
is 1 through 9, to indicate that the source substring matching the n
'th parenthesized subexpression of the pattern should be inserted, and it can contain \&
to indicate that the substring matching the entire pattern should be inserted. Write \\
if you need to put a literal backslash in the replacement text. The flags
parameter is an optional text string containing zero or more single-letter flags that change the function's behavior. Flag i
specifies case-insensitive matching, while flag g
specifies replacement of each matching substring rather than only the first one. Supported flags (though not g
) are described in Table 9.22.
Some examples:
The regexp_match
function returns a text array of captured substring(s) resulting from the first match of a POSIX regular expression pattern to a string. It has the syntax regexp_match
(string
, pattern
[, flags
]). If there is no match, the result is NULL
. If a match is found, and the pattern
contains no parenthesized subexpressions, then the result is a single-element text array containing the substring matching the whole pattern. If a match is found, and the pattern
contains parenthesized subexpressions, then the result is a text array whose n
'th element is the substring matching the n
'th parenthesized subexpression of the pattern
(not counting “non-capturing” parentheses; see below for details). The flags
parameter is an optional text string containing zero or more single-letter flags that change the function's behavior. Supported flags are described in Table 9.22.
Some examples:
In the common case where you just want the whole matching substring or NULL
for no match, write something like
The regexp_matches
function returns a set of text arrays of captured substring(s) resulting from matching a POSIX regular expression pattern to a string. It has the same syntax as regexp_match
. This function returns no rows if there is no match, one row if there is a match and the g
flag is not given, or N
rows if there are N
matches and the g
flag is given. Each returned row is a text array containing the whole matched substring or the substrings matching parenthesized subexpressions of the pattern
, just as described above for regexp_match
. regexp_matches
accepts all the flags shown in Table 9.22, plus the g
flag which commands it to return all matches, not just the first one.
Some examples:
In most cases regexp_matches()
should be used with the g
flag, since if you only want the first match, it's easier and more efficient to use regexp_match()
. However,regexp_match()
only exists in PostgreSQL version 10 and up. When working in older versions, a common trick is to place a regexp_matches()
call in a sub-select, for example:
This produces a text array if there's a match, or NULL
if not, the same as regexp_match()
would do. Without the sub-select, this query would produce no output at all for table rows without a match, which is typically not the desired behavior.
The regexp_split_to_table
function splits a string using a POSIX regular expression pattern as a delimiter. It has the syntax regexp_split_to_table
(string
, pattern
[, flags
]). If there is no match to the pattern
, the function returns the string
. If there is at least one match, for each match it returns the text from the end of the last match (or the beginning of the string) to the beginning of the match. When there are no more matches, it returns the text from the end of the last match to the end of the string. The flags
parameter is an optional text string containing zero or more single-letter flags that change the function's behavior. regexp_split_to_table
supports the flags described in Table 9.22.
The regexp_split_to_array
function behaves the same as regexp_split_to_table
, except that regexp_split_to_array
returns its result as an array of text
. It has the syntax regexp_split_to_array
(string
, pattern
[, flags
]). The parameters are the same as for regexp_split_to_table
.
Some examples:
As the last example demonstrates, the regexp split functions ignore zero-length matches that occur at the start or end of the string or immediately after a previous match. This is contrary to the strict definition of regexp matching that is implemented by regexp_match
and regexp_matches
, but is usually the most convenient behavior in practice. Other software systems such as Perl use similar definitions.
PostgreSQL's regular expressions are implemented using a software package written by Henry Spencer. Much of the description of regular expressions below is copied verbatim from his manual.
Regular expressions (REs), as defined in POSIX 1003.2, come in two forms: extended REs or EREs (roughly those of egrep
), and basic REs or BREs (roughly those of ed
). PostgreSQL supports both forms, and also implements some extensions that are not in the POSIX standard, but have become widely used due to their availability in programming languages such as Perl and Tcl. REs using these non-POSIX extensions are called advanced REs or AREs in this documentation. AREs are almost an exact superset of EREs, but BREs have several notational incompatibilities (as well as being much more limited). We first describe the ARE and ERE forms, noting features that apply only to AREs, and then describe how BREs differ.
PostgreSQL always initially presumes that a regular expression follows the ARE rules. However, the more limited ERE or BRE rules can be chosen by prepending an embedded option to the RE pattern, as described in Section 9.7.3.4. This can be useful for compatibility with applications that expect exactly the POSIX 1003.2 rules.
A regular expression is defined as one or more branches, separated by |
. It matches anything that matches one of the branches.
A branch is zero or more quantified atoms or constraints, concatenated. It matches a match for the first, followed by a match for the second, etc; an empty branch matches the empty string.
A quantified atom is an atom possibly followed by a single quantifier. Without a quantifier, it matches a match for the atom. With a quantifier, it can match some number of matches of the atom. An atom can be any of the possibilities shown in Table 9.15. The possible quantifiers and their meanings are shown in Table 9.16.
A constraint matches an empty string, but matches only when specific conditions are met. A constraint can be used where an atom could be used, except it cannot be followed by a quantifier. The simple constraints are shown in Table 9.17; some more constraints are described later.
Atom
Description
(
re
)
(where re
is any regular expression) matches a match for re
, with the match noted for possible reporting
(?:
re
)
as above, but the match is not noted for reporting (a “non-capturing” set of parentheses) (AREs only)
.
matches any single character
[
chars
]
\
k
(where k
is a non-alphanumeric character) matches that character taken as an ordinary character, e.g., \\
matches a backslash character
\
c
{
when followed by a character other than a digit, matches the left-brace character {
; when followed by a digit, it is the beginning of a bound
(see below)
x
where x
is a single character with no other significance, matches that character
An RE cannot end with a backslash (\
).
If you have standard_conforming_strings turned off, any backslashes you write in literal string constants will need to be doubled. See Section 4.1.2.1 for more information.
Quantifier
Matches
*
a sequence of 0 or more matches of the atom
+
a sequence of 1 or more matches of the atom
?
a sequence of 0 or 1 matches of the atom
{
m
}
a sequence of exactly m
matches of the atom
{
m
,}
a sequence of m
or more matches of the atom
{
m
,
n
}
a sequence of m
through n
(inclusive) matches of the atom; m
cannot exceed n
*?
non-greedy version of *
+?
non-greedy version of +
??
non-greedy version of ?
{
m
}?
non-greedy version of {
m
}
{
m
,}?
non-greedy version of {
m
,}
{
m
,
n
}?
non-greedy version of {
m
,
n
}
The forms using {
...
}
are known as bounds. The numbers m
and n
within a bound are unsigned decimal integers with permissible values from 0 to 255 inclusive.
Non-greedy quantifiers (available in AREs only) match the same possibilities as their corresponding normal (greedy) counterparts, but prefer the smallest number rather than the largest number of matches. See Section 9.7.3.5 for more detail.
A quantifier cannot immediately follow another quantifier, e.g., **
is invalid. A quantifier cannot begin an expression or subexpression or follow ^
or |
.
Constraint
Description
^
matches at the beginning of the string
$
matches at the end of the string
(?=
re
)
positive lookahead matches at any point where a substring matching re
begins (AREs only)
(?!
re
)
negative lookahead matches at any point where no substring matching re
begins (AREs only)
(?<=
re
)
positive lookbehind matches at any point where a substring matching re
ends (AREs only)
(?<!
re
)
negative lookbehind matches at any point where no substring matching re
ends (AREs only)
Lookahead and lookbehind constraints cannot contain back references (see Section 9.7.3.3), and all parentheses within them are considered non-capturing.
A bracket expression is a list of characters enclosed in []
. It normally matches any single character from the list (but see below). If the list begins with ^
, it matches any single character not from the rest of the list. If two characters in the list are separated by -
, this is shorthand for the full range of characters between those two (inclusive) in the collating sequence, e.g., [0-9]
in ASCII matches any decimal digit. It is illegal for two ranges to share an endpoint, e.g., a-c-e
. Ranges are very collating-sequence-dependent, so portable programs should avoid relying on them.
To include a literal ]
in the list, make it the first character (after ^
, if that is used). To include a literal -
, make it the first or last character, or the second endpoint of a range. To use a literal -
as the first endpoint of a range, enclose it in [.
and .]
to make it a collating element (see below). With the exception of these characters, some combinations using [
(see next paragraphs), and escapes (AREs only), all other special characters lose their special significance within a bracket expression. In particular, \
is not special when following ERE or BRE rules, though it is special (as introducing an escape) in AREs.
Within a bracket expression, a collating element (a character, a multiple-character sequence that collates as if it were a single character, or a collating-sequence name for either) enclosed in [.
and .]
stands for the sequence of characters of that collating element. The sequence is treated as a single element of the bracket expression's list. This allows a bracket expression containing a multiple-character collating element to match more than one character, e.g., if the collating sequence includes a ch
collating element, then the RE [[.ch.]]*c
matches the first five characters of chchcc
.
PostgreSQL currently does not support multi-character collating elements. This information describes possible future behavior.
Within a bracket expression, a collating element enclosed in [=
and =]
is an equivalence class, standing for the sequences of characters of all collating elements equivalent to that one, including itself. (If there are no other equivalent collating elements, the treatment is as if the enclosing delimiters were [.
and .]
.) For example, if o
and ^
are the members of an equivalence class, then [[=o=]]
, [[=^=]]
, and [o^]
are all synonymous. An equivalence class cannot be an endpoint of a range.
Within a bracket expression, the name of a character class enclosed in [:
and :]
stands for the list of all characters belonging to that class. Standard character class names are: alnum
, alpha
, blank
,cntrl
, digit
, graph
, lower
, print
, punct
, space
, upper
, xdigit
. These stand for the character classes defined in ctype. A locale can provide others. A character class cannot be used as an endpoint of a range.
There are two special cases of bracket expressions: the bracket expressions [[:<:]]
and [[:>:]]
are constraints, matching empty strings at the beginning and end of a word respectively. A word is defined as a sequence of word characters that is neither preceded nor followed by word characters. A word character is an alnum
character (as defined by ctype) or an underscore. This is an extension, compatible with but not specified by POSIX 1003.2, and should be used with caution in software intended to be portable to other systems. The constraint escapes described below are usually preferable; they are no more standard, but are easier to type.
Escapes are special sequences beginning with \
followed by an alphanumeric character. Escapes come in several varieties: character entry, class shorthands, constraint escapes, and back references. A \
followed by an alphanumeric character but not constituting a valid escape is illegal in AREs. In EREs, there are no escapes: outside a bracket expression, a \
followed by an alphanumeric character merely stands for that character as an ordinary character, and inside a bracket expression, \
is an ordinary character. (The latter is the one actual incompatibility between EREs and AREs.)
Character-entry escapes exist to make it easier to specify non-printing and other inconvenient characters in REs. They are shown in Table 9.18.
Class-shorthand escapes provide shorthands for certain commonly-used character classes. They are shown in Table 9.19.
A constraint escape is a constraint, matching the empty string if specific conditions are met, written as an escape. They are shown in Table 9.20.
A back reference (\
n
) matches the same string matched by the previous parenthesized subexpression specified by the number n
(see Table 9.21). For example, ([bc])\1
matches bb
or cc
but not bc
or cb
. The subexpression must entirely precede the back reference in the RE. Subexpressions are numbered in the order of their leading parentheses. Non-capturing parentheses do not define subexpressions.
Escape
Description
\a
alert (bell) character, as in C
\b
backspace, as in C
\B
synonym for backslash (\
) to help reduce the need for backslash doubling
\c
X
(where X
is any character) the character whose low-order 5 bits are the same as those of X
, and whose other bits are all zero
\e
the character whose collating-sequence name is ESC
, or failing that, the character with octal value 033
\f
form feed, as in C
\n
newline, as in C
\r
carriage return, as in C
\t
horizontal tab, as in C
\u
wxyz
(where wxyz
is exactly four hexadecimal digits) the character whose hexadecimal value is 0x
wxyz
\U
stuvwxyz
(where stuvwxyz
is exactly eight hexadecimal digits) the character whose hexadecimal value is 0x
stuvwxyz
\v
vertical tab, as in C
\x
hhh
(where hhh
is any sequence of hexadecimal digits) the character whose hexadecimal value is 0x
hhh
(a single character no matter how many hexadecimal digits are used)
\0
the character whose value is 0
(the null byte)
\
xy
(where xy
is exactly two octal digits, and is not a back reference) the character whose octal value is 0
xy
\
xyz
(where xyz
is exactly three octal digits, and is not a back reference) the character whose octal value is 0
xyz
Hexadecimal digits are 0
-9
, a
-f
, and A
-F
. Octal digits are 0
-7
.
Numeric character-entry escapes specifying values outside the ASCII range (0-127) have meanings dependent on the database encoding. When the encoding is UTF-8, escape values are equivalent to Unicode code points, for example \u1234
means the character U+1234
. For other multibyte encodings, character-entry escapes usually just specify the concatenation of the byte values for the character. If the escape value does not correspond to any legal character in the database encoding, no error will be raised, but it will never match any data.
The character-entry escapes are always taken as ordinary characters. For example, \135
is ]
in ASCII, but \135
does not terminate a bracket expression.
Escape
Description
\d
[[:digit:]]
\s
[[:space:]]
\w
[[:alnum:]_]
(note underscore is included)
\D
[^[:digit:]]
\S
[^[:space:]]
\W
[^[:alnum:]_]
(note underscore is included)
Within bracket expressions, \d
, \s
, and \w
lose their outer brackets, and \D
, \S
, and \W
are illegal. (So, for example, [a-c\d]
is equivalent to [a-c[:digit:]]
. Also, [a-c\D]
, which is equivalent to [a-c^[:digit:]]
, is illegal.)
Escape
Description
\A
\m
matches only at the beginning of a word
\M
matches only at the end of a word
\y
matches only at the beginning or end of a word
\Y
matches only at a point that is not the beginning or end of a word
\Z
A word is defined as in the specification of [[:<:]]
and [[:>:]]
above. Constraint escapes are illegal within bracket expressions.
Escape
Description
\
m
(where m
is a nonzero digit) a back reference to the m
'th subexpression
\
mnn
(where m
is a nonzero digit, and nn
is some more digits, and the decimal value mnn
is not greater than the number of closing capturing parentheses seen so far) a back reference to the mnn
'th subexpression
There is an inherent ambiguity between octal character-entry escapes and back references, which is resolved by the following heuristics, as hinted at above. A leading zero always indicates an octal escape. A single non-zero digit, not followed by another digit, is always taken as a back reference. A multi-digit sequence not starting with a zero is taken as a back reference if it comes after a suitable subexpression (i.e., the number is in the legal range for a back reference), and otherwise is taken as octal.
In addition to the main syntax described above, there are some special forms and miscellaneous syntactic facilities available.
An RE can begin with one of two special director prefixes. If an RE begins with ***:
, the rest of the RE is taken as an ARE. (This normally has no effect in PostgreSQL, since REs are assumed to be AREs; but it does have an effect if ERE or BRE mode had been specified by the flags
parameter to a regex function.) If an RE begins with ***=
, the rest of the RE is taken to be a literal string, with all characters considered ordinary characters.
An ARE can begin with embedded options: a sequence (?
xyz
)
(where xyz
is one or more alphabetic characters) specifies options affecting the rest of the RE. These options override any previously determined options — in particular, they can override the case-sensitivity behavior implied by a regex operator, or the flags
parameter to a regex function. The available option letters are shown in Table 9.22. Note that these same option letters are used in the flags
parameters of regex functions.
Option
Description
b
rest of RE is a BRE
c
case-sensitive matching (overrides operator type)
e
rest of RE is an ERE
i
m
historical synonym for n
n
p
q
rest of RE is a literal (“quoted”) string, all ordinary characters
s
non-newline-sensitive matching (default)
t
tight syntax (default; see below)
w
x
expanded syntax (see below)
Embedded options take effect at the )
terminating the sequence. They can appear only at the start of an ARE (after the ***:
director if any).
In addition to the usual (tight) RE syntax, in which all characters are significant, there is an expanded syntax, available by specifying the embedded x
option. In the expanded syntax, white-space characters in the RE are ignored, as are all characters between a #
and the following newline (or the end of the RE). This permits paragraphing and commenting a complex RE. There are three exceptions to that basic rule:
a white-space character or #
preceded by \
is retained
white space or #
within a bracket expression is retained
white space and comments cannot appear within multi-character symbols, such as (?:
For this purpose, white-space characters are blank, tab, newline, and any character that belongs to the space
character class.
Finally, in an ARE, outside bracket expressions, the sequence (?#
ttt
)
(where ttt
is any text not containing a )
) is a comment, completely ignored. Again, this is not allowed between the characters of multi-character symbols, like (?:
. Such comments are more a historical artifact than a useful facility, and their use is deprecated; use the expanded syntax instead.
None of these metasyntax extensions is available if an initial ***=
director has specified that the user's input be treated as a literal string rather than as an RE.
In the event that an RE could match more than one substring of a given string, the RE matches the one starting earliest in the string. If the RE could match more than one substring starting at that point, either the longest possible match or the shortest possible match will be taken, depending on whether the RE is greedy or non-greedy.
Whether an RE is greedy or not is determined by the following rules:
Most atoms, and all constraints, have no greediness attribute (because they cannot match variable amounts of text anyway).
Adding parentheses around an RE does not change its greediness.
A quantified atom with a fixed-repetition quantifier ({
m
}
or {
m
}?
) has the same greediness (possibly none) as the atom itself.
A quantified atom with other normal quantifiers (including {
m
,
n
}
with m
equal to n
) is greedy (prefers longest match).
A quantified atom with a non-greedy quantifier (including {
m
,
n
}?
with m
equal to n
) is non-greedy (prefers shortest match).
A branch — that is, an RE that has no top-level |
operator — has the same greediness as the first quantified atom in it that has a greediness attribute.
An RE consisting of two or more branches connected by the |
operator is always greedy.
The above rules associate greediness attributes not only with individual quantified atoms, but with branches and entire REs that contain quantified atoms. What that means is that the matching is done in such a way that the branch, or whole RE, matches the longest or shortest possible substring as a whole. Once the length of the entire match is determined, the part of it that matches any particular subexpression is determined on the basis of the greediness attribute of that subexpression, with subexpressions starting earlier in the RE taking priority over ones starting later.
An example of what this means:
In the first case, the RE as a whole is greedy because Y*
is greedy. It can match beginning at the Y
, and it matches the longest possible string starting there, i.e., Y123
. The output is the parenthesized part of that, or 123
. In the second case, the RE as a whole is non-greedy because Y*?
is non-greedy. It can match beginning at the Y
, and it matches the shortest possible string starting there, i.e., Y1
. The subexpression [0-9]{1,3}
is greedy but it cannot change the decision as to the overall match length; so it is forced to match just 1
.
In short, when an RE contains both greedy and non-greedy subexpressions, the total match length is either as long as possible or as short as possible, according to the attribute assigned to the whole RE. The attributes assigned to the subexpressions only affect how much of that match they are allowed to “eat” relative to each other.
The quantifiers {1,1}
and {1,1}?
can be used to force greediness or non-greediness, respectively, on a subexpression or a whole RE. This is useful when you need the whole RE to have a greediness attribute different from what's deduced from its elements. As an example, suppose that we are trying to separate a string containing some digits into the digits and the parts before and after them. We might try to do that like this:
That didn't work: the first .*
is greedy so it “eats” as much as it can, leaving the \d+
to match at the last possible place, the last digit. We might try to fix that by making it non-greedy:
That didn't work either, because now the RE as a whole is non-greedy and so it ends the overall match as soon as possible. We can get what we want by forcing the RE as a whole to be greedy:
Controlling the RE's overall greediness separately from its components' greediness allows great flexibility in handling variable-length patterns.
When deciding what is a longer or shorter match, match lengths are measured in characters, not collating elements. An empty string is considered longer than no match at all. For example: bb*
matches the three middle characters of abbbc
; (week|wee)(night|knights)
matches all ten characters of weeknights
; when (.*).*
is matched against abc
the parenthesized subexpression matches all three characters; and when (a*)*
is matched against bc
both the whole RE and the parenthesized subexpression match an empty string.
If case-independent matching is specified, the effect is much as if all case distinctions had vanished from the alphabet. When an alphabetic that exists in multiple cases appears as an ordinary character outside a bracket expression, it is effectively transformed into a bracket expression containing both cases, e.g., x
becomes [xX]
. When it appears inside a bracket expression, all case counterparts of it are added to the bracket expression, e.g., [x]
becomes [xX]
and [^x]
becomes [^xX]
.
If newline-sensitive matching is specified, .
and bracket expressions using ^
will never match the newline character (so that matches will never cross newlines unless the RE explicitly arranges it) and ^
and $
will match the empty string after and before a newline respectively, in addition to matching at beginning and end of string respectively. But the ARE escapes \A
and \Z
continue to match beginning or end of string only.
If partial newline-sensitive matching is specified, this affects .
and bracket expressions as with newline-sensitive matching, but not ^
and $
.
If inverse partial newline-sensitive matching is specified, this affects ^
and $
as with newline-sensitive matching, but not .
and bracket expressions. This isn't very useful but is provided for symmetry.
No particular limit is imposed on the length of REs in this implementation. However, programs intended to be highly portable should not employ REs longer than 256 bytes, as a POSIX-compliant implementation can refuse to accept such REs.
The only feature of AREs that is actually incompatible with POSIX EREs is that \
does not lose its special significance inside bracket expressions. All other ARE features use syntax which is illegal or has undefined or unspecified effects in POSIX EREs; the ***
syntax of directors likewise is outside the POSIX syntax for both BREs and EREs.
Many of the ARE extensions are borrowed from Perl, but some have been changed to clean them up, and a few Perl extensions are not present. Incompatibilities of note include \b
, \B
, the lack of special treatment for a trailing newline, the addition of complemented bracket expressions to the things affected by newline-sensitive matching, the restrictions on parentheses and back references in lookahead/lookbehind constraints, and the longest/shortest-match (rather than first-match) matching semantics.
Two significant incompatibilities exist between AREs and the ERE syntax recognized by pre-7.4 releases of PostgreSQL:
In AREs, \
followed by an alphanumeric character is either an escape or an error, while in previous releases, it was just another way of writing the alphanumeric. This should not be much of a problem because there was no reason to write such a sequence in earlier releases.
In AREs, \
remains a special character within []
, so a literal \
within a bracket expression must be written \\
.
BREs differ from EREs in several respects. In BREs, |
, +
, and ?
are ordinary characters and there is no equivalent for their functionality. The delimiters for bounds are \{
and \}
, with {
and }
by themselves ordinary characters. The parentheses for nested subexpressions are \(
and \)
, with (
and )
by themselves ordinary characters. ^
is an ordinary character except at the beginning of the RE or the beginning of a parenthesized subexpression, $
is an ordinary character except at the end of the RE or the end of a parenthesized subexpression, and *
is an ordinary character if it appears at the beginning of the RE or the beginning of a parenthesized subexpression (after a possible leading ^
). Finally, single-digit back references are available, and \<
and \>
are synonyms for [[:<:]]
and [[:>:]]
respectively; no other escapes are available in BREs.
a bracket expression, matching any one of the chars
(see for more detail)
where c
is alphanumeric (possibly followed by other characters) is an escape, see (AREs only; in EREs and BREs, this matches c
)
matches only at the beginning of the string (see for how this differs from ^
)
matches only at the end of the string (see for how this differs from $
)
case-insensitive matching (see ) (overrides operator type)
newline-sensitive matching (see )
partial newline-sensitive matching (see )
inverse partial newline-sensitive (“weird”) matching (see )