PostgreSQL 開發者的語言伺服器來了：postgres-lsp 正式發布

Supabase Community · 2026-06-21（PostgreSQL.org 公告）

Supabase 社群正式對外發布 postgres-lsp，一款專為 PostgreSQL SQL 與 PL/pgSQL 打造的語言伺服器，實作了業界標準的 Language Server Protocol（LSP）。這項專案歷經兩年開發，於 2025 年 3 月首次對外宣布，如今已發展至 v0.25.4，並在 PostgreSQL.org 社群公告頻道於 2026 年 6 月 21 日正式列為官方消息。這是 PostgreSQL 生態系中首個以 Rust 為核心、基於官方剖析器的語言伺服器實作。

為什麼 PostgreSQL 需要自己的語言伺服器？

SQL 開發長期缺乏像 TypeScript 或 Rust 那樣完整的 IDE 輔助工具。現有方案多半依賴通用語法著色或簡易的關鍵字補全，無法理解 PostgreSQL 特有的方言、函數語義或 schema 結構。postgres-lsp 的核心設計理念是：「最小編譯單元是單一 SQL 陳述句，資料庫 schema 是唯一的真理來源。」這讓語言伺服器能夠在不完整輸入的情況下仍然提供有意義的診斷與補全。

開發團隊在早期曾嘗試打造一個自訂的「輕量剖析器」，逐一處理不同陳述句型別的邊界案例，但後來承認這是「永無止境的邊界案例陷阱」。最終他們轉向更務實的方向：用簡單的 Pratt Parser 處理常見模式，並以分號或雙換行作為後備切分策略，在 80% 的使用情境上做到足夠好。這個「抵抗完美主義、優先考量實用方案」的原則，貫穿了整個架構設計。

雙剖析器架構：libpg_query 加上 tree-sitter

postgres-lsp 採用兩個互補的剖析器協同運作。libpg_query 是直接從 PostgreSQL 原始碼萃取的官方剖析器，負責處理語法正確的 SQL 並提供精確的錯誤訊息；tree-sitter 則處理使用者正在輸入、尚未完整的陳述句，提供即時的語法樹以支援補全與診斷。這個組合確保了剖析結果與 PostgreSQL 伺服器行為的高度一致性。

在效能設計上，語言伺服器採用「schema 懶加載快取」策略：資料表、欄位、函數、型別等 schema 資訊只在需要時才從資料庫讀取並存入記憶體，後續補全請求直接命中快取而不觸發額外查詢。當文件被編輯時，系統只會重新分析受影響的陳述句，其餘陳述句僅更新位置範圍，讓診斷結果能夠「無感延遲」地即時呈現。

目前支援的功能

自動補全：具備智慧排名的建議清單，融合 schema 資訊
語法錯誤診斷：偵測無效的 SQL 結構
型別檢查：透過 PostgreSQL EXPLAIN 功能的錯誤洞察進行型別驗證
程式碼格式化：SQL 程式碼格式整理
Migration linting：schema 遷移腳本的靜態分析，靈感來自 squawk
Database linting：直接針對資料庫 schema 進行分析
PL/pgSQL 支援：PostgreSQL 程序語言

支援的編輯器與存取方式

postgres-lsp 以 Rust 撰寫（佔程式碼庫 59.2%），並透過多種管道提供存取：LSP 協定、命令列介面（CLI）、HTTP API，以及 WebAssembly 模組。編輯器支援已涵蓋 VSCode（官方擴充套件）、Cursor、Neovim（透過 nvim-lspconfig 和 mason）、Zed 與 Sublime Text。CLI 安裝可透過 GitHub releases 或 npm 套件取得。

目前 GitHub 上已累積 5,200 顆星與 121 個 fork，並有 37 個正式釋出版本。開發團隊在路線圖上列出的近期優先事項包括：可靠性強化、擴大編輯器支援、完整文件，以及未來對 PL/pgSQL、pglite WebAssembly 構建和 SQL 函數本體剖析的支援。目前已有 18 個 open issue，顯示社群積極回饋中。

原始來源：supabase-community/postgres_lsp（GitHub）、Supabase Blog 公告

Redis 8.8 發布：原生陣列型別、內建限流器與跨指令大幅效能躍升

redis.io · 2026-06-02

Redis 官方於 2026 年 6 月 2 日由工程師 Lior Kogan 發布 Redis 8.8 公告，帶來七項主要新功能與廣泛的效能改善。本次最大亮點是全新的 Array 資料結構，提供原生索引定址集合，隨機讀寫效能比 List 快 5 至 8 倍。此外，原生 Window Counter 限流器的引入，讓開發者無需再依賴 Lua 腳本實作速率限制邏輯。

全新 Array 資料結構：`AR*` 指令族群

Redis 8.8 引入了全新的 Array 型別，這是一個通用的、可索引定址的字串值集合，支援動態大小調整與稀疏存取，並具備伺服器端聚合運算能力。與現有的 List 相比，Array 的隨機讀寫效能提升 5 至 8 倍（以 100K 元素、1KB 值為基準，讀取達 675K ops/sec vs List 的 133K ops/sec）。

Array 同時支援環形緩衝區（ring buffer）模式，取代以往 RPUSH + LTRIM 的組合，操作速度約快 2 倍。相關指令包含完整的 18 個新指令，涵蓋 ARINSERT、ARGET、ARSET、ARMGET、ARMSET、ARRING、AROP（支援 SUM/MIN/MAX 聚合）等。Array 的記憶體開銷約比 List 多 18%，但遠低於 Hash 的 30–46%。

# 環形緩衝區寫入（保留最近 1000 筆）
ARRING mylog 1000 "event-data"

# 伺服器端聚合（範圍內求和）
AROP myarray SUM 0 99

Window Counter Rate Limiter：`INCREX` 指令

新的 INCREX 指令實作了 Window Counter 演算法，讓開發者無需 Lua 腳本即可完成原生限流。指令支援設定 token 容量（UBOUND）與時間視窗（EX／PX），並提供三種失敗模式：SILENT（靜默允許）、FAIL（返回錯誤）、FATAL（計數器凍結直到過期），分別對應不同的限流策略場景。

# 每秒最多 100 次請求，超過時返回錯誤
INCREX user:rate:abc 1 UBOUND 100 EX 1 FAIL

Streams NACKing 與 Hash 欄位層級通知

新增的 XNACK 指令讓 Redis Streams 的消費者群組能夠明確拒絕訊息，而非只能 ACK 或忽略。三種模式各有語義：SILENT 減少投遞計數（暫時性失敗）、FAIL 保持計數不變（資源限制）、FATAL 將計數設為 LLONG_MAX（毒訊息永久標記）。被 NACK 的訊息會在 PEL（Pending Entries List）中優先排隊重新投遞。

Hash 型別新增了欄位層級的 Pub/Sub 事件通知，透過新的頻道類型 subkeyspace、subkeyevent 訂閱 hset、hdel、hexpire 等七種事件。這讓精細化的即時變更感知成為可能，不再需要訂閱整個 keyspace 再自行過濾。

效能改善總覽

資料型別	操作	改善幅度
Strings	MGET（I/O threads 管線化）	最高 68%
Strings	MGET（單執行緒管線化）	最高 50%
Hash	HGETALL（1K+ 欄位）	最高 25%
Streams	XREADGROUP COUNT 100	最高 83%
Sorted Sets	ZADD、ZINCRBY、ZRANGEBYSCORE	最高 74%
Scan	SCAN、HSCAN、SSCAN、ZSCAN	最高 40%
持久化／複寫	Full sync	最高 60% 加速

其他新功能：時間序列與 JSON 精度控制

Time Series 模組新增了在單一 TS.RANGE 指令中同時指定多個聚合器的能力，語法為逗號分隔的聚合清單（如 MIN,MAX,FIRST,LAST），讓繪製 K 線圖等需要同時取得多種統計值的場景，可從多次查詢降為單次查詢。

JSON 型別新增了 FPHA（Floating Point Hint Array）參數，可在 JSON.SET 時明確指定浮點數精度格式：BF16、FP16、FP32、FP64。這對儲存 AI 嵌入向量（embedding）特別有用，選用 BF16 可大幅降低記憶體用量，同時保留足夠的數值精度。 Redis 8.8 現已可從 redis.io/downloads 取得。

原始來源：Announcing Redis 8.8（redis.io Blog）

End of article