從 Postgres 11.2 對 Greenplum 5.17.0 作 Materialized View

好久以前有紀錄從 Postgres 開 postgres_fdw 連線到 Greenplum 的筆記，前一陣子又看到 Materialized Views and Foreign Data Wrappers | EnterpriseDB 這篇文章，拿來試著對 Greenplum 試試看～

在 Postgres 11 的 Materialized View，進行刷新（REFRESH MATERILAIZED VIEW）會把資料整組清掉，重新查詢並把結果拉回來快取。

現在，要透過 Foreign Data Wrapper，搭配 Materialized View，從 Greenplum（基於 PostgreSQL 的延伸專案）把查詢拉到 Postgres 裡面。

EDB 11 新功能 — 內建資料遮碼（Data Redaction）

EDB 的企業版 EDB Postgres Advanced Server 11 新增了幾個內建新功能，其中一個是資料遮碼功能（Data Redaction）。
這個功能主要是把資料打叉叉的功能，其實這已經在 SQL Server 跟 Oracle 有提供了，但是 Postgres 需要 DIY 處理，日前 EDB 有提供教學文章～
現在 EDB 直接提供整合的管理，應用上更貼近 SQL Server 跟 Oracle 一些，不用像使用純 PGSQL 要 DIY；而且 DIY 的物件一多起來，維護人員就會眼花撩亂了～

在這邊整合資料遮碼以及外部表作該功能的練習～

把 iris 資料集放進 PGSQL

iris 資料集，是資料分析的入門範例資料集，很多的入門教學都會用到這份資料作範例。這邊把大統計學家 Ronald Fisher 使用的 iris 資料拿來匯入 PGSQL 裡面，用一點點 PGSQL 的功能讓儲存便簡潔一點點，順便把裡面提到的幾項敘述統計量整理成一個 VIew。以便作為延伸學習的敲門磚～～

做一隻 Alpine Linux v3.8 的開機隨身碟～

這裡紀錄把近期 docker Container 流行的小型 linux 之一，Alpine Linux，弄到隨身碟上面，變成 RAMDisk OS 的筆記。
這個跟實際把 Alpine Linux 裝起來是不一樣的～
當然，這篇筆記跟 docker Container 也沒什麼關係～

在 PGSQL 裡面把 SQL_ASCII Database 裡面的 Multibytes Encoding 資料轉換到 UTF8 Database

很舊以前，Big5 的資料會放到裡面，不讓資料庫去處理內容。就是所謂的 Garbage in, garbage out. 。這種設置方式是把 PGSQL 資料庫初始化成 LATIN1 的資料庫（也就是 SQL_ASCII 的意思～）。若是 Oracle 的話，則是 iso-8859-1（與 Linux 的 file 指令查看 ASCII 資料所顯示的 MIME 名稱一樣～）
到了現在以 UTF8 為主流編碼的氛圍，可能就會想要把上面這種設置換掉，變成正統 UTF8 編碼，以利於資料交換的使用。
若現在資料已經在 PGSQL 的話，可以怎麼做呢？這邊用一個簡單的例子作練習。

EDB 的 Postgres 企業版的 Docker 容器 v2.3 簡易試用筆記

近日 PostgreSQL 的企業版服務公司 EnterpriseDB 提供了其企業版產品的 Docker 容器服務。只要是 Docker Container 引擎為基礎的容器平台（Docker CE，Docker EE 或其他像 Red Hat OpenShift 平台等）都可以在認證後登入 EDB 提供的 Docker Registry（訂閱期間的用戶都可以～）去拉資料庫的 Image。

這裡簡單紀錄一下 Docker CE 裡面對 EDB Container Registry v2.3 的功能體驗筆記。

在 Postgres 10 擴增 Big5 中文難字 — 從原始碼開始（用 Big5-2003 字碼集）

PostgreSQL 不支援「直接」儲存 Big5 編碼（聽說很古老的版本有支援，但我不清楚...），因此目前的 PGSQL 資料庫支援 Big5 的方式，是把裡面存放的 UTF8 編碼資料，利用內建編碼表，轉換成 Big5 編碼，再把資料送往 Client 端。如果前端送來的是 Big5 編碼，指名 client_encoding 之後，PGSQL 就會進行編碼轉換，以 UTF8 存放到資料庫裡面。

由於 Postgres 會嚴謹檢查資料的規格，不符的會拒絕吃進來，因此遇到沒有內建的 Big5 ↔ UTF8 編碼，會拒絕該筆資料，回傳錯誤。

PGSQL 10 支援的是標準字區，以及 CP950 （可以到 Unicode 官方網站找到 CP950 原始對照表）的 0xf9d6-0xf9d 部份（這件事寫在原始碼的 UCS_to_BIG5.pl 這份 Perl Script 裡面）。在這個範圍之外的 Big5 字碼，對 PGSQL 都是從缺，沒有對應。

但是，上述被拒絕的狀況，在台灣偏偏是常常發生...原因是，過往很多系統都會有自造 Big5 字碼，通常會依照各自單位的內部規則，這些自造字用的字碼區，偏偏又在 PGSQL 不認得的區段，所以會發生錯誤..

因此，這裡要紀錄的是，如何從原始碼擴增字碼，讓 PGSQL 認得自造 Big5 字碼。