v1.4.2

Release v1.4.2

發布日期 (Date): 2026-11-10

主要亮點 (Highlights):

• 修正同時移除欄位與該欄位外鍵時部署失敗（42704 constraint ... does not exist）的問題；42704 錯誤不再一律附上「缺少 extension」的誤導提示。
• Fixed deployments failing with 42704 constraint ... does not exist when a column and its foreign key are removed together; 42704 errors no longer always carry the misleading "missing extension" hint.

---

🌟 What's New / 主要更新

🚀 Features / 新功能

*「無 / None」

🛠 Refactoring & Improvements / 重構與效能優化

• 42704 錯誤提示更精準：原本只要遇到 42704 undefined_object 就附上「通常是缺少 PostgreSQL extension」的提示，但 constraint、index 不存在也屬於 42704。現在只有錯誤訊息為「型別不存在」（type "..." does not exist）時才附上此提示；42883 undefined_function 維持不變。

  EN: More accurate hint for 42704 errors: the "often caused by a missing PostgreSQL extension" hint used to be appended to every 42704 undefined_object error, although missing constraints or indexes also raise 42704. The hint is now added only when the message reports a missing type (type "..." does not exist); 42883 undefined_function is unchanged.

🐛 Bug Fixes / 問題修復

• 修正同時移除欄位與其外鍵時部署失敗：SQL 定義檔把某欄位連同其外鍵一起移除（例如把 ServiceId + FK_..._ServiceId 換成 ScanTargetId + FK_..._ScanTargetId）時，Table Changes 群組原本先執行 DROP COLUMN 再執行 DROP CONSTRAINT。PostgreSQL 刪除欄位時會自動刪除該欄位上的約束，導致後續 DROP CONSTRAINT 失敗（42704），整個群組回滾。現在 Table Changes 群組的語句順序為：外鍵的 DROP CONSTRAINT（DropForeignKey、RecreateForeignKey 的刪除部分）最前，接著主鍵的 DROP CONSTRAINT（RecreatePrimaryKey 的刪除部分），其餘語句依差異順序在後。規則記錄於 docs/dev-guide-architecture.md，後續新增會刪除約束的變更類型時，須一併放入前置刪除清單。

  EN: Fixed deployments failing when a column is removed together with its foreign key: when a SQL definition removed a column and its foreign key at the same time (e.g. replacing ServiceId + FK_..._ServiceId with ScanTargetId + FK_..._ScanTargetId), the Table Changes group ran DROP COLUMN before DROP CONSTRAINT. PostgreSQL drops a column's constraints automatically, so the subsequent DROP CONSTRAINT failed with 42704 and the whole group rolled back. The Table Changes group now runs foreign-key DROP CONSTRAINT statements first (DropForeignKey and the drop part of RecreateForeignKey), then primary-key DROP CONSTRAINT statements (the drop part of RecreatePrimaryKey), followed by all other statements in diff order. The rule is documented in docs/dev-guide-architecture.md; any future change type that drops a constraint must also go into this pre-drop list.

⚠️ Breaking Changes / 重大變更

*「無 / None」

v1.4.1

Release v1.4.1

發布日期 (Date): 2026-11-03

主要亮點 (Highlights):

• 修正 partial index（WHERE）部署時會操作到錯誤索引、回報成功卻沒有建立的問題；View 重建時若 DROP VIEW ... CASCADE 會刪除 schema 目錄外的 View，現在會中止部署並回傳錯誤，不再默默刪除。
• Fixed partial indexes (WHERE) being deployed against the wrong index and reported as successful without being created. When rebuilding a View would make DROP VIEW ... CASCADE drop views outside the schema directory, the deployment is now aborted with an error instead of silently dropping them.

---

🌟 What's New / 主要更新

🚀 Features / 新功能

• CASCADE 會刪除 schema 目錄外物件時阻擋部署：View 需要先刪除再重建時，工具會在分析階段透過 pg_depend / pg_rewrite 遞迴找出 DROP VIEW ... CASCADE 會連帶刪除的 View / Materialized View（含其他 schema）。若其中有不在 schema 目錄中的物件，部署計畫會列出 [BLOCKED] 與受影響的物件，deploy、deploy --dry-run、diff 皆回傳 exit code 1，且不執行任何群組。確定要刪除時，可使用 CLI --allow-cascade-drop、JSON 設定 options.allowCascadeDrop: true，或 WPF 設定頁「允許 CASCADE 刪除 schema 目錄外的 View」明確放行，此時改以 [!] caution 顯示。執行階段（DeployOrchestrator.ExecuteAsync）會依當下設定再判斷一次，所有呼叫端都受保護。

  EN: Block deployments when CASCADE would drop objects outside the schema directory: when a View must be dropped and recreated, the analyzer now walks pg_depend / pg_rewrite recursively to find every View / Materialized View (including other schemas) that DROP VIEW ... CASCADE would also drop. If any of them is not defined in the schema directory, the plan lists them under [BLOCKED], and deploy, deploy --dry-run and diff all exit with code 1 without running any group. To proceed intentionally, use the CLI flag --allow-cascade-drop, the JSON option options.allowCascadeDrop: true, or the WPF setting "Allow CASCADE to drop views outside the schema directory"; the item is then shown as a [!] caution. DeployOrchestrator.ExecuteAsync re-evaluates the policy with the settings in effect at execution time, so every host is protected.

• View 只在尾端新增欄位時不再刪除重建：既有 View 的欄位清單若只是在尾端新增欄位，改以 CREATE OR REPLACE VIEW 直接更新（CLI 顯示 [+VCOL]），不再插入 Drop Views (Pre-Alter)，依賴它的其他 View 不受影響。欄位改名、刪除、改順序或在中間插入時仍會先刪除再重建（[~VIEW]）。

  EN: No drop-and-recreate when a View only appends columns: if an existing View's column list only gains new columns at the end, it is now updated in place with CREATE OR REPLACE VIEW (shown as [+VCOL] in the CLI) without a Drop Views (Pre-Alter) step, so views depending on it are untouched. Renaming, removing, reordering or inserting columns in the middle still drops and recreates the View ([~VIEW]).

• 在既有資料表建立唯一索引時提示：對既有資料表建立或重建 UNIQUE 索引時列為 [!] caution，提醒若現有資料有重複鍵，部署會失敗並回滾該群組。

  EN: Caution for unique indexes on existing tables: creating or recreating a UNIQUE index on an existing table is now flagged as a [!] caution, warning that the deployment will fail and roll back that group if existing rows contain duplicate keys.

🛠 Refactoring & Improvements / 重構與效能優化

• 索引內省與比對改寫：SchemaIntrospector 改由 pg_index 直接取得索引的欄位／運算式、DESC、INCLUDE 欄位、存取方法與 WHERE 條件，不再以正規式切割 pg_get_indexdef() 的輸出。比對前，對 SQL 檔與資料庫寫法不同的同名索引（如 IN (...) 被改寫為 = ANY (ARRAY[...])、運算式被補上型別轉換），會在交易內建立暫存表與相同索引，讀回 PostgreSQL 正規化後的定義再比較，最後整個交易回滾、不留下任何物件。因此分析（含 dry-run）需要目標資料庫的 TEMP 權限；沒有權限時退回以 SQL 原文比對。

  EN: Rewritten index introspection and comparison: SchemaIntrospector now reads index columns/expressions, DESC flags, INCLUDE columns, access method and WHERE predicate directly from pg_index instead of regex-splitting pg_get_indexdef(). When a same-named index is written differently in the SQL file and in the database (e.g. IN (...) rewritten as = ANY (ARRAY[...]), or expressions gaining type casts), the analyzer creates a temp table and the same index inside a transaction, reads back PostgreSQL's normalized definition for comparison, and rolls the transaction back so nothing is left behind. Analysis (including dry-run) therefore needs the TEMP privilege on the target database; without it, the comparison falls back to the SQL text as written.

• 索引定義原樣部署：SQL 檔中的 CREATE INDEX 會完整保留 WHERE、INCLUDE、USING、WITH、opclass 等子句並原樣執行；因部署群組在交易內執行，CONCURRENTLY 會自動移除。註解中的 CREATE INDEX 不再被誤解析為索引。

  EN: Index definitions are deployed as written: CREATE INDEX statements from SQL files keep all clauses (WHERE, INCLUDE, USING, WITH, opclasses, etc.) and are executed verbatim; CONCURRENTLY is removed automatically because deployment groups run inside a transaction. CREATE INDEX text inside comments is no longer parsed as an index.

• CLI / WPF 顯示補強：CLI 補上 [~CMT]（註解變更）、[+VIEW]、[~VIEW]、[+VCOL] 前綴（原本註解與 View 變更顯示為 [?]）；WPF 為 View 變更與阻擋項目加上顏色。

  EN: CLI / WPF display improvements: the CLI now shows [~CMT] (comment changes), [+VIEW], [~VIEW] and [+VCOL] prefixes (comment and View changes previously showed [?]); WPF adds colors for View changes and blocked items.

🐛 Bug Fixes / 問題修復

• 修正 partial index 部署錯誤：建立或重建索引時原本以 Description.Contains(name) 反查索引，名稱互為子字串（如 IX_X 與 UIX_X_...）時會操作到錯誤的索引，導致 dry-run 顯示建立 UIX_...、實際卻執行 IX_...，部署回報成功但索引沒有建立，資料中的重複鍵也不會被發現。此外 WHERE 條件在解析與產生 SQL 時被丟棄，內省時又把 WHERE (...) 誤當成欄位清單，使已存在的 partial index 每次部署都被判定為「定義已變更」。現在改以完全相同的索引名稱比對，並完整保留與比對 WHERE 條件。

  EN: Fixed partial index deployment: index changes were resolved with Description.Contains(name), so when one index name contained another (e.g. IX_X and UIX_X_...) the wrong index was operated on. Dry-run showed UIX_... being created while IX_... was actually executed, the deployment reported success without creating the index, and duplicate keys went unnoticed. The WHERE clause was also dropped during parsing and SQL generation, and introspection mistook WHERE (...) for the column list, so existing partial indexes were reported as "definition changed" on every deployment. Indexes are now matched by exact name and their WHERE predicate is preserved and compared.

• 修正資料表欄位改型別／刪除時被 View 依賴而部署失敗：schema 目錄中的 View 若（直接或間接）引用本次要變更型別或刪除的資料表欄位，現在會先刪除並於 Views 群組重建，避免 PostgreSQL 拒絕 ALTER TABLE（cannot alter type of a column used by a view or rule）。

  EN: Fixed failures when altering or dropping a column used by a View: Views in the schema directory that (directly or indirectly) reference a table column whose type is being changed or which is being dropped are now dropped first and recreated in the Views group, preventing PostgreSQL from rejecting the ALTER TABLE (cannot alter type of a column used by a view or rule).

• 修正漏分號時難以定位的錯誤訊息：資料表 SQL 檔整份以單一 command 執行，CREATE INDEX ... ) 或 CREATE TABLE ... ) 漏了 ; 時原本只顯示 42601: syntax error at or near "COMMENT"。現在於解析階段即回報檔名與行號（如 Tables\B_Bad.sql: Line 9: ...），dry-run 就能發現；執行失敗時也會附上來源檔名，語法錯誤可確定位置時附上行號。

  EN: Fixed hard-to-locate errors for missing semicolons: table SQL files are executed as a single command, so a missing ; after CREATE INDEX ... ) or CREATE TABLE ... ) used to produce only 42601: syntax error at or near "COMMENT". The file name and line number are now reported during parsing (e.g. Tables\B_Bad.sql: Line 9: ...), so dry-run catches it; execution failures also include the source file name, plus the line number when the syntax error position can be determined.

⚠️ Breaking Changes / 重大變更

• CASCADE 會刪除 schema 目錄外的 View 時，部署改為失敗：過去這類部署會照常執行並默默刪除那些 View；v1.4.1 起 deploy、deploy --dry-run、diff 會回傳 exit code 1，CD 流程會因此中止。升級方式：

  • 建議：把被列出的 View 定義檔加入 schema 目錄，之後每次部署都會自動重建。
  • 或確認可以刪除後，在 CLI 加上 --allow-cascade-drop、在 JSON 設定檔加上 "options": { "allowCascadeDrop": true }，或在 WPF 設定頁勾選對應選項。

  EN: Deployments now fail when CASCADE would drop views outside the schema directory: previously such deployments ran and silently dropped those views. Starting with v1.4.1, deploy, deploy --dry-run and diff exit with code 1, which stops CD pipelines. Migration:

  • Recommended: add the listed views' definition files to the schema directory so they are recreated on every deployment.
  • Or, once you have confirmed they can be dropped, pass --allow-cascade-drop to the CLI, set "options": { "allowCascadeDrop": true } in the JSON config, or enable the corresponding option in the WPF settings.

• ISchemaIntrospector 介面新增成員（僅影響自行實作此介面的程式）：新增 CanonicalizeIndexesAsync、GetViewDependentsAsync、GetViewsDependingOnColumnsAsync；ChangeType 列舉在最後新增 ExtendView，既有成員數值不變。

  EN: New members on ISchemaIntrospector (affects only custom implementations of this interface): CanonicalizeIndexesAsync, GetViewDependentsAsync and GetViewsDependingOnColumnsAsync were added; ChangeType gains ExtendView at the end, so existing member values are unchanged.

v1.4.0

Release v1.4.0

發布日期 (Date): 2026-06-03

主要亮點 (Highlights):

• 新增資料表與欄位註解同步支援，現在部署工具會解析 SQL 定義中的 COMMENT ON TABLE / COMMENT ON COLUMN，並在差異比對與部署時正確更新 PostgreSQL 註解內容。
• Added support for synchronizing table and column comments. The deployer now parses COMMENT ON TABLE / COMMENT ON COLUMN definitions from SQL files and applies comment changes during schema diffing and deployment.

---

🌟 What's New / 主要更新

🚀 Features / 新功能

• 資料表與欄位註解同步支援：SqlFileParser 現在可從 Table SQL 檔中解析 COMMENT ON TABLE 與 COMMENT ON COLUMN，並將註解資訊納入 TableSchema / ColumnDefinition 模型。SchemaIntrospector 也會從 PostgreSQL 讀取現有的 table comment 與 column comment，讓 SchemaDiffer 可以在 SQL 定義與資料庫現況之間正確比對註解差異，並由 DeployOrchestrator / SqlGenerator 產生對應的 COMMENT ON ... 更新語句。

  EN: Table and column comment synchronization support: SqlFileParser now parses COMMENT ON TABLE and COMMENT ON COLUMN statements from table SQL files and stores them in the TableSchema / ColumnDefinition models. SchemaIntrospector also reads existing table and column comments from PostgreSQL, allowing SchemaDiffer to detect comment changes correctly and DeployOrchestrator / SqlGenerator to emit the corresponding COMMENT ON ... update statements.

---

🛠 Refactoring & Improvements / 重構與效能優化

• 新增欄位時自動補上欄位註解：當部署流程偵測到 AddColumn 變更時，若 SQL 定義中該欄位同時包含 comment，系統會在 ALTER TABLE ... ADD COLUMN 後接續產生 COMMENT ON COLUMN，避免新增欄位成功但註解遺漏的情況。

  EN: Automatically apply column comments for newly added columns: When an AddColumn change is detected and the SQL definition includes a comment for that column, the deployer now emits a follow-up COMMENT ON COLUMN statement after ALTER TABLE ... ADD COLUMN, preventing newly added columns from missing their comments.

• 補強註解同步測試覆蓋：新增 SqlFileParserTests、SchemaDifferTests 與 SqlGeneratorTests，涵蓋 comment 解析、註解差異偵測、SQL 產生與單引號跳脫等情境，降低後續回歸風險。

  EN: Expanded test coverage for comment synchronization: Added SqlFileParserTests, SchemaDifferTests, and SqlGeneratorTests to cover comment parsing, diff detection, SQL generation, and single-quote escaping scenarios, reducing regression risk in future changes.

---

🐛 Bug Fixes / 問題修復

• 修正 Table 部署流程未同步 COMMENT 的問題：過去工具在處理既有資料表異動時，只會比對欄位型別、Nullable、Default、PK、Index、FK 等結構資訊，未將 table / column comment 納入變更分析，因此即使 SQL 定義檔已更新註解內容，部署後資料庫中的 comment 仍不會同步。現在 comment 已納入完整的 parse → introspect → diff → generate → deploy 流程。

  EN: Fixed missing COMMENT synchronization in table deployment: Previously, the deployment workflow compared structural changes such as column types, nullability, defaults, primary keys, indexes, and foreign keys, but ignored table and column comments. As a result, updated comments in SQL definition files were not propagated to the database. Comment metadata is now included throughout the full parse → introspect → diff → generate → deploy pipeline.

---

⚠️ Breaking Changes / 重大變更

無 / None

v1.3.2

Release v1.3.2

發布日期 (Date): 2026-05-31

主要亮點 (Highlights):

• 修正 View Script 含單行 SQL 註解（--）時，差異比對邏輯誤判 View 需要重建的問題，並同步修正 double-quoted 識別符導致的 FROM 關鍵字誤判。
• Fixed an issue where single-line SQL comments (--) in View scripts caused the diff engine to incorrectly detect the View as needing a rebuild. Also fixed misidentification of the FROM keyword inside double-quoted identifiers.

---

🌟 What's New / 主要更新

🚀 Features / 新功能

無 / None

---

🛠 Refactoring & Improvements / 重構與效能優化

無 / None

---

🐛 Bug Fixes / 問題修復

• View 差異比對誤判修正：當 View 的 AS 子句後緊接單行 SQL 註解（-- 開頭）時，SchemaDiffer 在提取 SELECT 本體前未先跳過這些注釋行，導致比對邏輯無法正確解析 View 結構，進而錯誤判斷 View 需要重建。現在會在提取 SELECT 本體前，逐行略過所有前置 -- 單行注釋。

  EN: View diff false-positive rebuild fix: When a View's AS clause was followed by one or more -- single-line comments before the SELECT body, SchemaDiffer failed to strip those comment lines prior to parsing, causing the diff engine to misidentify the View as changed and trigger an unnecessary rebuild. The fix pre-strips all leading -- comment lines before extracting the SELECT body.

• ExtractSelectList double-quoted 識別符誤判修正：ExtractSelectList 在掃描 FROM 關鍵字時，未跳過 double-quoted 識別符（如欄位名稱 "FromName"）內的字元，導致識別符中的 FROM 文字被誤認為關鍵字，造成 SELECT 清單截取錯誤。現在掃描過程中會正確追蹤 "..." 範圍並跳過其內容。

  EN: ExtractSelectList double-quoted identifier fix: The ExtractSelectList scanner did not skip characters inside double-quoted identifiers (e.g., a column named "FromName"), so the literal text FROM inside such identifiers was mistakenly treated as the FROM keyword, producing an incorrect SELECT column list. The scanner now tracks "..." ranges and skips their contents.

---

⚠️ Breaking Changes / 重大變更

無 / None

v1.3.1

Release v1.3.1

發布日期 (Date): 2026-05-26

主要亮點 (Highlights):

• 修復 View 部署時因 SELECT * 或非引號 Schema 前綴導致的 PostgreSQL 錯誤 42P16: cannot change name of view column，讓 View 差異比對與同步更加穩健可靠。
• EN: Fixes PostgreSQL error 42P16: cannot change name of view column triggered by SELECT * views or unquoted schema prefixes (e.g. public."vw_name"), making View diff and sync more robust and reliable.

🌟 What's New / 主要更新

🚀 Features / 新功能

無 / None

---

🛠 Refactoring & Improvements / 重構與效能優化

無 / None

---

🐛 Bug Fixes / 問題修復

• View 差異比對：SELECT * 視圖改為保守的 ReplaceView 策略

  當現有 View 的 SQL 使用 SELECT * 導致欄位無法靜態解析時，舊版本會靜默跳過（不標記為任何變更），可能導致欄位實際有異動卻未觸發部署，進而發生 PostgreSQL 錯誤 42P16。修正後改為保守地標記為 ReplaceView（先執行 DROP VIEW，再執行 CREATE OR REPLACE VIEW），確保 View 結構一致性。

  EN: View diff: SELECT * views now use conservative ReplaceView strategy

  Previously, when an existing View's SQL used SELECT * (columns unparseable at diff time), it was silently skipped — potentially missing real column changes and causing PostgreSQL error 42P16. The fix marks such views as ReplaceView (DROP then CREATE OR REPLACE), ensuring structural consistency even when column names cannot be statically determined.

• View 名稱解析：Regex 支援非引號 Schema 前綴（如 public."vw_name"）

  View 名稱解析的正則表達式原本僅支援完整引號格式（如 "public"."vw_name"），對非引號 Schema 前綴（如 public."vw_name"）無法正確識別 View 名稱，導致 View 被誤認為「不存在」而以 CreateView 執行，觸發 PostgreSQL 錯誤 42P16。現已同時支援 \w+ 非引號 Schema 格式，涵蓋 DeployOrchestrator 與 SchemaDiffer 中所有相關 Regex。

  EN: View name parsing: Regex now supports unquoted schema prefix (e.g. public."vw_name")

  The View name extraction regex previously only handled fully-quoted schemas (e.g. "public"."vw_name"). An unquoted schema prefix like public."vw_name" would fail to match, causing the View to be treated as non-existent and deployed as CreateView — which then triggered PostgreSQL error 42P16. All related Regex patterns in both DeployOrchestrator and SchemaDiffer now accept \w+ unquoted schema prefixes.

---

⚠️ Breaking Changes / 重大變更

無 / None

v1.3.0

Release v1.3.0

發布日期 (Date): 2026-05-26

主要亮點 (Highlights):

• 新增外鍵（Foreign Key）完整管理能力，支援自動偵測、比對與安全部署
• EN: Full foreign key management support with automatic detection, comparison, and safe deployment

🌟 What's New / 主要更新

🚀 Features / 新功能

• 新增外鍵差異比對與自動同步

  • 自動偵測新增的外鍵、刪除的外鍵、以及定義變更的外鍵
  • 支援外鍵約束名稱、欄位清單、被參照表、ON DELETE/ON UPDATE 動作的完整比對
  • 在部署計劃中清晰呈現外鍵變更，包含風險警告

  EN:

  • Auto-detects new, dropped, and modified foreign keys
  • Full comparison including constraint names, columns, referenced table, and referential actions (ON DELETE/ON UPDATE)
  • Clear deployment plan visualization with caution messages for data consistency risks

• 外鍵定義與內省

  • 支援從 SQL 定義檔解析 FOREIGN KEY 約束（含 ON DELETE/ON UPDATE）
  • 支援從資料庫內省現有外鍵約束結構

  EN:

  • Parse FOREIGN KEY constraints from SQL files with referential action support
  • Query existing foreign keys from PostgreSQL information schema

• 改進 CLI 顯示

  • 部署計劃中新增外鍵變更的視覺標籤：[+FK]（新增）、[-FK]（刪除）、[~FK]（重建）

  EN:

  • Visual indicators in deployment plan: [+FK] for additions, [-FK] for drops, [~FK] for recreations

🛠 Refactoring & Improvements / 重構與效能優化

• 新增本地化資源：外鍵變更訊息（中英雙語）

  • 包含詳細的風險警告，提醒使用者外鍵變更對資料完整性的影響

  EN: Added localized messages for foreign key changes with data consistency warnings in both English and Traditional Chinese

• 擴充 TableSchema 模型

  • 新增 ForeignKeys 集合，與現有的 Indexes 並行管理

  EN: Extended TableSchema with ForeignKeys collection to parallel index management

🐛 Bug Fixes / 問題修復

• 無 / None

⚠️ Breaking Changes / 重大變更

• 無 / None

v1.2.0

Release v1.2.0

發布日期 (Date): 2026-05-23

主要亮點 (Highlights):

• 新增智能 View 差異比對與自動同步功能，支援欄位變更偵測與安全的 View 重建流程
• EN: Added intelligent view difference detection and automatic synchronization. Views are now intelligently tracked and safely rebuilt when column definitions change.

🌟 What's New / 主要更新

🚀 Features / 新功能

• 新增 View 差異比對與智能同步

  • 自動偵測 View 變更：識別新增的 View、偵測欄位名稱或順序改變
  • 安全部署流程：當 View 欄位改變時，系統會在表格異動前先 DROP 舊 View 後重建，避免 PostgreSQL 不支援的操作
  • 支援複雜 SQL 解析：能正確提取包含別名、巢狀括號、引號識別符的 View 定義

  EN:

  • Auto-detects View additions and column changes (name, count, or order)
  • Safe deployment: Views are dropped and recreated before table changes to prevent incompatible operations
  • Robust SQL parsing for complex SELECT statements

• 改進部署日誌與可視化

  • 日誌現在顯示資料表和 View 的數量
  • Diff 結果在部署計畫中清晰呈現

  EN:

  • Deployment logs now display both table and View counts
  • View changes are clearly shown in the deployment plan

🛠 Refactoring & Improvements / 重構與效能優化

• SchemaChange 模型屬性重命名：TableName → EntityName

  • 原因：屬性現在同時表示表格或 View，需要更通用的名稱
  • 受影響檔案已全數更新

  EN: Renamed SchemaChange.TableName to EntityName for semantic clarity. The property now represents either a table or View name. All impacted files have been updated.

• 新增本地化資源字符串：View 變更的多語言支援

  EN: Added localized resource strings for View change messages

🐛 Bug Fixes / 問題修復

• 無 / None

⚠️ Breaking Changes / 重大變更

• 無 / None

v1.1.1

Release v1.1.1

發布日期 (Date): 2026-05-01

主要亮點 (Highlights):

• 修正多張資料表有 FOREIGN KEY 互相依賴時，因字母排序導致建立順序錯誤而部署失敗的問題；同步修正含 schema 前綴的 INDEX 定義被誤判為需刪除的錯誤。
• EN: Fixed a deployment failure caused by alphabetical table ordering conflicting with FOREIGN KEY dependencies. Also fixed a false positive that incorrectly marked schema-prefixed index definitions (e.g., ON public."TableName") for deletion.

🌟 What's New / 主要更新

🚀 Features / 新功能

• 無 / None

🛠 Refactoring & Improvements / 重構與效能優化

• 無 / None

🐛 Bug Fixes / 問題修復

• [修復] 含 FOREIGN KEY 的資料表因字母排序錯誤導致部署失敗
  部署新資料表時，若多張表之間存在 FOREIGN KEY 約束（如 EIP_DevOps_Commit_Repo 參照 EIP_DevOps_Commit），舊版依檔名字母順序執行，被引用的資料表可能在依賴者之後才建立，觸發 42P01: relation "xxx" does not exist 錯誤。
  現於 DeployOrchestrator.AnalyzeAsync 中新增 TopologicalSortTables()（Kahn 演算法），在進入 diff 前自動以 FK 依賴進行拓撲排序；若存在迴圈依賴則保留原始順序附加於末尾。

  EN: [Fix] Deployment failure when new tables have FOREIGN KEY dependencies with alphabetical ordering conflict
  When deploying new tables with FOREIGN KEY constraints (e.g., EIP_DevOps_Commit_Repo references EIP_DevOps_Commit), the previous alphabetical file ordering could cause the referenced table to be created after its dependent, triggering 42P01: relation "xxx" does not exist.
  Added TopologicalSortTables() (Kahn's algorithm) in DeployOrchestrator.AnalyzeAsync. Tables are now topologically sorted by FK dependency before the diff phase. Circular dependencies fall back to original order.

• [修復] 含 schema 前綴的 INDEX 定義被誤判為需刪除
  SQL 檔案中使用 ON public."TableName"(...) 格式定義的索引，舊版 IndexPattern regex 無法解析 schema 前綴，導致工具每次都誤判這些 INDEX 為「資料庫中有、但 SQL 定義中不存在」而產生 DROP INDEX 指令。
  已將 SqlFileParser.IndexPattern 調整為支援可選的 schema. 前綴：ON\s+(?:[a-zA-Z_]\w*\.)?""([^""]+)"" 。

  EN: [Fix] Index definitions with schema prefix incorrectly flagged as extra indexes to drop
  Index definitions using the ON public."TableName"(...) format were not matched by the previous IndexPattern regex, causing the tool to incorrectly generate DROP INDEX statements on every run for those indexes.
  Updated SqlFileParser.IndexPattern to support an optional schema. prefix: ON\s+(?:[a-zA-Z_]\w*\.)?""([^""]+)"".

⚠️ Breaking Changes / 重大變更

• 無 / None

v1.1.0

發布日期 (Release Date): 2026-03-18

主要亮點 (Highlights):

• 新增 Connection String 支持，簡化 CI/CD 配置流程，密鑰管理更加安全
• 新增自動建立資料庫功能，首次部署無需預先建立目標資料庫
• 完全向後相容，現有部署流程無需任何改動

---

🌟 What's New / 主要更新

🚀 Features / 新功能

1. Connection String 支持（推薦用於 CI/CD）

• 使用 --connection-string 或 -s 參數直接傳入完整連接字符串
• 無需逐一指定 host、port、database、username、password 各參數
• 特別適合 CI/CD 環境，配合密鑰管理系統使用

EN: Connection String Support - Use --connection-string (or -s alias) to pass a complete PostgreSQL connection string. Perfect for CI/CD pipelines with secret management systems.

使用範例 / Usage Example:

pgdeploy deploy \
  --config PostgresDeployer.json \
  --connection-string "Host=localhost;Database=mydb;Username=user;Password=secret" \
  --yes

2. 自動建立資料庫功能

• 啟用 --create-db-if-not-exists 選項，部署時若目標資料庫不存在會自動建立
• 支援配置檔案設定或命令列參數
• 首次部署更方便，無需 DBA 預先建立空資料庫

EN: Auto-Create Database - Enable --create-db-if-not-exists to allow automatic database creation during deployment. No need to pre-create the database manually.

設定方法 / Configuration:

• 配置檔案："createDatabaseIfNotExists": true
• 命令列：pgdeploy deploy --config PostgresDeployer.json --create-db-if-not-exists --yes

3. WPF 圖形介面新增設置選項

• Settings 頁面新增「Auto-create database if it does not exist」複選框
• Test Connection 按鈕可驗證伺服器連接狀態

EN: WPF Settings - GUI now offers "Auto-create database if it does not exist" option in Deploy Options.

🐛 Bug Fixes / 問題修復

• Connection String 解析修復，確保配置優先級正確應用

  EN: Connection string parsing improvements for correct parameter precedence

• WPF 連接測試改善，支援新的自動建立資料庫選項

  EN: WPF connection testing improved to support auto-create database option

⚠️ Breaking Changes / 重大變更

• 無 (None) - 此版本完全向後相容，現有部署流程無需任何修改

  EN: None - Fully backward compatible with version 1.0.x

---

📝 使用指南 / Usage Guide

升級建議

1. 如果您目前使用個別參數（如 --host、--port、--database），可繼續使用 ✅

   # 舊方法，仍然有效
   pgdeploy deploy \
     --config PostgresDeployer.json \
     --host localhost \
     --database mydb \
     --username user \
     --password secret \
     --yes

2. 新版推薦：改用 Connection String（特別是 CI/CD 環境） 🚀

   # 新方法，更簡潔更安全
   pgdeploy deploy \
     --config PostgresDeployer.json \
     --connection-string "$DB_CONNSTR" \
     --yes

首次部署操作流程

如果是第一次部署到新環境，建議使用自動建立資料庫功能：

# 方法一：使用 Connection String + 自動建立資料庫
pgdeploy deploy \
  --config PostgresDeployer.json \
  --connection-string "Host=db.example.com;Database=newapp;Username=admin;Password=secret" \
  --create-db-if-not-exists \
  --yes

# 方法二：預先在配置檔案中啟用此選項
# 編輯 PostgresDeployer.json，在 options 中設定：
# "createDatabaseIfNotExists": true

---

❓ 常見問題 / FAQ

Q: 我應該使用 Connection String 還是個別參數？

A: 如果在 CI/CD 環境，強烈推薦使用 Connection String，可直接使用密鑰管理系統傳入。本地開發可繼續使用個別參數。

Q: 啟用自動建立資料庫需要什麼權限？

A: PostgreSQL 用戶需要 CREATEDB 權限。如無此權限，請聯繫資料庫管理員或預先手動建立資料庫。

Q: 這個版本與 1.0.x 相容嗎？

A: 完全相容。所有現有配置檔案和命令都能正常運作。新功能是完全可選的。

---

感謝使用 PostgresDeployer！如有任何問題，請參考 README
Thank you for using PostgresDeployer! For more information, see README

v1.0.2

發布日期 (Date): 2026-03-06

主要亮點 (Highlights):

• 簡化路徑設定方式：不再需要 basePath + 子目錄的兩層結構，schema 與 initData 直接指定完整路徑即可
• EN: Simplified path configuration — schema and initData now take full directory paths directly, eliminating the need for a basePath + subdirectory two-layer structure

🌟 What's New / 主要更新

🚀 Features / 新功能

• 無 / None

🛠 Refactoring & Improvements / 重構與效能優化

• 路徑設定簡化：Config 檔與 CLI 中的 schema 和 initData 現在直接填入完整目錄路徑，不再需要透過 basePath 組合。設定更直覺，減少路徑拼接造成的錯誤

  EN: Simplified path configuration: schema and initData in config files and CLI now accept full directory paths directly, without needing basePath to combine. This makes configuration more intuitive and reduces path-resolution errors

🐛 Bug Fixes / 問題修復

• 無 / None

⚠️ Breaking Changes / 重大變更

• CLI --base-path 選項已移除：請改用 --schema 與 --init-data 直接指定目錄的完整路徑

  EN: CLI --base-path option removed: Use --schema and --init-data to specify full directory paths directly

• Config 檔格式變更：paths 區段不再支援 basePath 欄位，請將 schema 與 initData 更新為完整路徑。升級範例：

  EN: Config file format changed: The basePath field under paths is no longer supported. Update schema and initData to full paths. Migration example:

  // 舊格式 (Before)
  "paths": {
    "basePath": "C:/MyProject",
    "schema": "Schema",
    "initData": "InitData"
  }
  
  // 新格式 (After)
  "paths": {
    "schema": "C:/MyProject/Schema",
    "initData": "C:/MyProject/InitData"
  }