Goose — เปลี่ยน schema แบบย้อนกลับได้

docker run -d --name pg-shop \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=shopdb \
  -p 55433:5432 \
  postgres:16

# เช็คว่าขึ้นแล้วจริง
docker exec -it pg-shop psql -U postgres -d shopdb -c 'SELECT 1;'

docker exec -it pg-shop psql -U postgres -d shopdb

export PATH="$PATH:$(go env GOPATH)/bin"

1 · migration กับ seed ต่างกันตรงไหน

แต่คำว่า "seed" ในโลกจริงหมายถึงสองอย่างที่ต่างกันคนละเรื่อง และนี่คือจุดที่คนสับสนที่สุด:

2 · ทำไมห้าม migrate ด้วยมือ

"ก็แค่เข้า psql แล้วพิมพ์ ALTER TABLE เอง จะยากอะไร" — มันยากตรงสองข้อนี้:

   1) DB ที่คุณกำลังจะแก้ มีข้อมูลของคนอื่นอยู่แล้ว

      ALTER TABLE products ADD COLUMN stock INT NOT NULL;
      └───┬────┘ └──┬───┘ └────┬────┘ └─┬─┘ └───┬────┘
       แก้ตาราง  ชื่อตาราง  เพิ่มคอลัมน์  ชนิด  ห้ามเป็นค่าว่าง
                                            ▲
                                            └── แถวเก่า 50,000 แถวที่มีอยู่แล้ว
                                                จะเอาค่าอะไรใส่ในคอลัมน์ใหม่นี้?
                                                เราสั่งว่า "ห้ามว่าง" แต่ไม่ได้บอกว่า
                                                ถ้าไม่มีค่าให้ใช้อะไรแทน (DEFAULT)
                                                → Postgres ปฏิเสธทั้งคำสั่ง ตารางไม่เปลี่ยน

      แก้ได้ด้วยการบอกค่าตั้งต้นไปด้วย:
      ALTER TABLE products ADD COLUMN stock INT NOT NULL DEFAULT 0;

   2) พิมพ์ไปแล้วในเครื่อง dev — ใครจำได้ว่าต้องไปพิมพ์ซ้ำที่ไหนอีก?

      dev   ──▶ ALTER แล้ว
      staging ─▶ ?
      prod  ──▶ ?          ไม่มีใครรู้ว่า DB ตัวไหนอยู่สถานะไหน

เครื่องมือ migration แก้สองข้อนี้ด้วยวิธีเดียวกัน: เปลี่ยนคำสั่ง SQL ให้กลายเป็น "ไฟล์ที่อยู่ใน git" แล้วให้ database จำเองว่ารันไฟล์ไหนไปแล้วบ้าง
พอเป็นไฟล์ ก็ได้ของแถมมาสองอย่าง: รีวิวได้ก่อน merge และ เขียนวิธีย้อนกลับติดไว้ในไฟล์เดียวกัน

3 · AutoMigrate ของบทเรียน 27 ทำอะไรไม่ได้บ้าง

ก่อนจะไปที่ goose ต้องตอบให้ได้ก่อนว่า ทำไมของที่มีอยู่แล้วถึงไม่พอ
ผมเปิด PostgreSQL 16 ขึ้นมาหนึ่งตัว แล้วรัน AutoMigrate จริง 5 รอบ รอบละ struct ที่ต่างกันนิดเดียว

// step1 — รันครั้งแรก สร้างตาราง แล้ว insert Keyboard 1200 กับ Mouse 590
type Product struct {
    ID    uint   `gorm:"primaryKey"`
    Name  string `gorm:"not null"`
    Price float64
}

// step2 — เปลี่ยนชื่อ field จาก Price เป็น Cost แล้วรัน AutoMigrate อีกที
type Product struct {
    ID    uint   `gorm:"primaryKey"`
    Name  string `gorm:"not null"`
    Cost  float64
    Stock int
}

db.AutoMigrate(&Product{})

AutoMigrate step2 OK

                            Table "public.products"
 Column |  Type   | Collation | Nullable |               Default
--------+---------+-----------+----------+--------------------------------------
 id     | bigint  |           | not null | nextval('products_id_seq'::regclass)
 name   | text    |           | not null |
 price  | numeric |           |          |
 cost   | numeric |           |          |
 stock  | bigint  |           |          |

 id |   name   | price | cost | stock
----+----------+-------+------+-------
  1 | Keyboard |  1200 |      |
  2 | Mouse    |   590 |      |
(2 rows)

ผมไล่ทดลองต่อจนครบ นี่คือสิ่งที่ AutoMigrate ทำได้และทำไม่ได้ ทั้งหมดยืนยันด้วยการรันจริง:

AutoMigrate step3 OK
EXIT=0
 Column |  Type   | Collation | Nullable |               Default
--------+---------+-----------+----------+--------------------------------------
 cost   | numeric |           |          |

และเมื่อ AutoMigrate ตัดสินใจผิด คุณไม่มีทางย้อน เพราะไม่มีที่ไหนบันทึกไว้ว่ามันทำอะไรไป ลองดูตอนที่มันเจอข้อมูลแปลงไม่ได้ (คอลัมน์ stock เป็น text แล้วมีคำว่า ten อยู่ พอเปลี่ยน struct กลับเป็น int):

2026/08/18 19:54:58 /..../step5/main.go:20 ERROR: invalid input syntax for type bigint: "ten" (SQLSTATE 22P02)
[3.165ms] [rows:0] ALTER TABLE "products" ALTER COLUMN "stock" TYPE bigint USING "stock"::bigint
AutoMigrate ERROR: ERROR: invalid input syntax for type bigint: "ten" (SQLSTATE 22P02)

สังเกตบรรทัดกลาง — ALTER TABLE ... USING "stock"::bigint คือ SQL ที่ GORM แต่งขึ้นเองตอน runtime โดยไม่มีใครเคยเห็นมาก่อน
นี่คือความต่างที่แท้จริง: migration ของ goose คือ "สคริปต์ที่รีวิวได้ก่อน merge" ส่วน AutoMigrate คือ "SQL ลึกลับที่เกิดตอนแอป start"
แอปตัวนี้พังตอน boot บน production โดยที่ไม่มีใครเคยเห็น ALTER บรรทัดนั้นในโค้ดรีวิวเลยสักครั้ง

4 · ติดตั้ง goose แล้วสร้างไฟล์แรก

go install github.com/pressly/goose/v3/cmd/goose@latest
which goose      # ติดตั้งลงที่ไหน
goose --version  # ได้เวอร์ชันไหนมา

/Users/tuwanon/go/bin/goose
goose version: v3.27.3

goose เป็น CLI (โปรแกรมที่พิมพ์เรียกใน terminal) แยกต่างหาก ไม่ใช่ library ที่ import เข้าไปในโค้ดโปรเจกต์ — binary ไปอยู่ที่ $GOPATH/bin เหมือนเครื่องมือ Go ตัวอื่น ๆ
ก่อนใช้ต้องบอกมันสามอย่าง: driver อะไร (driver = ตัวเชื่อมที่รู้วิธีคุยกับ DB ยี่ห้อนั้น ๆ ของเราคือ postgres) · ต่อ DB ไหน · ไฟล์อยู่โฟลเดอร์ไหน ซึ่งวิธีที่สบายที่สุดคือไฟล์ .env ที่ goose อ่านให้เองอัตโนมัติ

# .env ที่รากโปรเจกต์ — goose อ่านให้เอง (flag -env ค่า default คือ .env)
GOOSE_DRIVER=postgres
GOOSE_DBSTRING=postgres://postgres:secret@localhost:55433/shopdb?sslmode=disable
GOOSE_MIGRATION_DIR=./migrations

Usage: goose DRIVER DBSTRING [OPTIONS] COMMAND

or

Set environment key
GOOSE_DRIVER=DRIVER
GOOSE_DBSTRING=DBSTRING
GOOSE_MIGRATION_DIR=MIGRATION_DIR
(EXIT=1)

# ต่อ DB ได้ แต่ลืมบอกโฟลเดอร์ (ค่า default ของ -dir คือ "." ไม่ใช่ "./migrations")
2026/08/18 19:52:49 goose run: no migration files found

# -dir ชี้ไปที่ที่ไม่มีอยู่จริง
2026/08/18 19:52:49 goose run: ./nope directory does not exist

# dbstring ผิด port — อ่านให้ดี ข้อความยาว 5 บรรทัด ไม่ใช่ 3
2026/08/18 19:52:49 goose run: failed to connect to `user=postgres database=shopdb`:
	[::1]:59999 (localhost): dial error: dial tcp [::1]:59999: connect: connection refused
	127.0.0.1:59999 (localhost): dial error: dial tcp 127.0.0.1:59999: connect: connection refused; failed to connect to `user=postgres database=shopdb`:
	[::1]:59999 (localhost): dial error: dial tcp [::1]:59999: connect: connection refused
	127.0.0.1:59999 (localhost): dial error: dial tcp 127.0.0.1:59999: connect: connection refused

พอมี .env แล้วก็สร้างไฟล์แรกได้:

$ goose create create_products_table sql
2026/08/18 19:50:33 Created new file: migrations/20260818125033_create_products_table.sql

ถ้าทีมเล็กและอยากได้เลขอ่านง่าย มี flag -s (sequential) ให้:

$ goose -s create init sql
2026/08/18 19:53:42 Created new file: migrations/00001_init.sql
$ goose -s create add_users sql
2026/08/18 19:53:42 Created new file: migrations/00002_add_users.sql

อ่านง่ายกว่าจริง แต่แลกมาด้วยความเสี่ยง: สองคนสร้างไฟล์พร้อมกันในคนละ branch จะได้เลขเดียวกัน แล้วชน conflict ตอน merge — ทีมใหญ่จึงใช้ timestamp

5 · โครงไฟล์ migration — annotation ที่ต้องพิมพ์เอง

ไฟล์ที่ goose create สร้างให้ มีแค่นี้จริง ๆ:

-- +goose Up
SELECT 'up SQL query';

-- +goose Down
SELECT 'down SQL query';

ทีนี้มาดูว่าแต่ละ annotation ทำอะไร:

ไฟล์แรกจริง ๆ ของโปรเจกต์เรา:

-- 20260818125033_create_products_table.sql
-- +goose Up
CREATE TABLE products (
    id         BIGSERIAL PRIMARY KEY,
    name       TEXT NOT NULL,
    price      NUMERIC(10,2) NOT NULL DEFAULT 0,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- +goose Down
DROP TABLE products;

สังเกตว่า ทุกอย่างที่ Up ทำ Down ต้องมีคำสั่งย้อนคู่กัน — สร้างตารางคู่กับลบตาราง เพิ่มคอลัมน์คู่กับลบคอลัมน์ สร้าง index คู่กับลบ index

เมื่อไหร่ที่ต้องใช้ StatementBegin

ผมเขียน trigger ที่อัปเดต updated_at อัตโนมัติแบบตรงไปตรงมา — SQL ชุดนี้ copy ไปวางใน psql รันผ่านฉลุย แต่ goose up พัง:

2026/08/18 19:51:38 goose run: ERROR 20260818125138_add_updated_at_trigger.sql: failed to run SQL migration:
failed to execute SQL query "CREATE OR REPLACE FUNCTION set_updated_at() RETURNS trigger AS $$\nBEGIN\n    NEW.updated_at = now();":
ERROR: unterminated dollar-quoted string at or near "$$
BEGIN
    NEW.updated_at = now();" (SQLSTATE 42601)

อ่าน error ให้ดี — SQL ที่ goose ส่งไปที่ DB จบลงที่ NEW.updated_at = now(); พอดี
เพราะ goose แบ่ง statement ด้วยการมอง ; แบบง่าย ๆ มันไม่รู้จัก dollar-quoted string ($$) ของ Postgres เลยตัด function ขาดครึ่งกลางตัว

-- 20260818125138_add_updated_at_trigger.sql
-- +goose Up
ALTER TABLE products ADD COLUMN updated_at TIMESTAMPTZ NOT NULL DEFAULT now();

-- +goose StatementBegin      ← ครอบเฉพาะ block ที่มี ; อยู่ข้างใน
CREATE OR REPLACE FUNCTION set_updated_at() RETURNS trigger AS $$
BEGIN
    NEW.updated_at = now();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- +goose StatementEnd

CREATE TRIGGER trg_products_updated_at
BEFORE UPDATE ON products
FOR EACH ROW EXECUTE FUNCTION set_updated_at();

-- +goose Down
DROP TRIGGER trg_products_updated_at ON products;
DROP FUNCTION set_updated_at();
ALTER TABLE products DROP COLUMN updated_at;

2026/08/18 19:51:54 OK   20260818125138_add_updated_at_trigger.sql (3.77ms)
2026/08/18 19:51:54 goose: successfully migrated database to version: 20260818125138

6 · up · down · status · version

สมมติมี 3 ไฟล์ในโฟลเดอร์ migrations/ แล้วยังไม่เคยรันอะไรเลย:

$ goose status
2026/08/18 19:50:50     Applied At                  Migration
2026/08/18 19:50:50     =======================================
2026/08/18 19:50:50     Pending                  -- 20260818125033_create_products_table.sql
2026/08/18 19:50:50     Pending                  -- 20260818125034_add_stock_to_products.sql
2026/08/18 19:50:50     Pending                  -- 20260818125035_add_index_products_name.sql

$ goose version
2026/08/18 19:50:50 goose: version 0

              List of relations
 Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | goose_db_version | table | postgres
(1 row)

 id | version_id | is_applied |           tstamp
----+------------+------------+----------------------------
  1 |          0 | t          | 2026-08-18 12:50:50.954417
(1 row)

$ goose up
2026/08/18 19:51:01 OK   20260818125033_create_products_table.sql (17.69ms)
2026/08/18 19:51:01 OK   20260818125034_add_stock_to_products.sql (5.54ms)
2026/08/18 19:51:01 OK   20260818125035_add_index_products_name.sql (5.95ms)
2026/08/18 19:51:01 goose: successfully migrated database to version: 20260818125035

$ goose version
2026/08/18 19:51:01 goose: version 20260818125035

$ goose status
2026/08/18 19:51:01     Applied At                  Migration
2026/08/18 19:51:01     =======================================
2026/08/18 19:51:01     Tue Aug 18 12:51:01 2026 -- 20260818125033_create_products_table.sql
2026/08/18 19:51:01     Tue Aug 18 12:51:01 2026 -- 20260818125034_add_stock_to_products.sql
2026/08/18 19:51:01     Tue Aug 18 12:51:01 2026 -- 20260818125035_add_index_products_name.sql

up รันเรียงตามเลข version จากน้อยไปมาก ปิดท้ายด้วยบรรทัดสรุป version ล่าสุด
สังเกตอีกครั้ง: prefix ซ้ายมือคือ 19:51 (เวลาไทย) แต่คอลัมน์ Applied At คือ 12:51 (UTC) — บรรทัดเดียวสองโซนเวลา

goose down ย้อนกลับ ทีละหนึ่งไฟล์ จากบนสุดลงมา:

$ goose down
2026/08/18 19:51:19 OK   20260818125035_add_index_products_name.sql (11.81ms)

-- ก่อน down
Indexes:
    "products_pkey" PRIMARY KEY, btree (id)
    "idx_products_name" btree (name)

-- หลัง down — index หายไปจริง
Indexes:
    "products_pkey" PRIMARY KEY, btree (id)

นอกจาก 4 คำสั่งหลัก ยังมีคำสั่งที่ใช้บ่อยพอควรอีกชุด (ทั้งหมดรันจริงแล้ว):

2026/08/18 19:55:27 OK   20260818125100_add_sku_to_products.sql (2.67ms)
2026/08/18 19:55:27 OK   20260818125100_add_sku_to_products.sql (2.14ms)

7 · เปิดตาราง goose_db_version — จุดที่ทำให้เข้าใจทั้งบท

ทุกอย่างในบทนี้ตัดสินด้วยตารางเดียว มาดูกันว่ามันเก็บอะไรบ้าง:

$ psql -c '\d goose_db_version'

                                  Table "public.goose_db_version"
   Column   |            Type             | Collation | Nullable |             Default
------------+-----------------------------+-----------+----------+----------------------------------
 id         | integer                     |           | not null | generated by default as identity
 version_id | bigint                      |           | not null |
 is_applied | boolean                     |           | not null |
 tstamp     | timestamp without time zone |           | not null | now()
Indexes:
    "goose_db_version_pkey" PRIMARY KEY, btree (id)

หลัง goose up 3 ไฟล์ ข้อมูลในตารางเป็นแบบนี้:

 id |   version_id   | is_applied |           tstamp
----+----------------+------------+----------------------------
  1 |              0 | t          | 2026-08-18 12:50:50.954417
  2 | 20260818125033 | t          | 2026-08-18 12:51:01.789388
  3 | 20260818125034 | t          | 2026-08-18 12:51:01.80727
  4 | 20260818125035 | t          | 2026-08-18 12:51:01.812882
(4 rows)

version_id คือตัวเลขหน้าชื่อไฟล์ตรง ๆ · แถว version_id = 0 คือแถวเริ่มต้นที่ goose ใส่ให้ตอนสร้างตาราง

ทีนี้คำถามสำคัญ — goose down ทำอะไรกับตารางนี้?

$ goose down
2026/08/18 19:51:19 OK   20260818125035_add_index_products_name.sql (11.81ms)

 id |   version_id   | is_applied |           tstamp
----+----------------+------------+----------------------------
  1 |              0 | t          | 2026-08-18 12:50:50.954417
  2 | 20260818125033 | t          | 2026-08-18 12:51:01.789388
  3 | 20260818125034 | t          | 2026-08-18 12:51:01.80727
(3 rows)

8 · seed ที่รันซ้ำแล้วข้อมูลไม่ซ้ำ

กลับมาที่หัวข้อ 1 — ผมเขียน seed master data เป็น migration ธรรมดา ไม่มี ON CONFLICT ไม่มีอะไรกันซ้ำเลย:

-- 20260818125201_seed_categories.sql
-- +goose Up
INSERT INTO categories (code, name) VALUES
    ('ELEC', 'Electronics'),
    ('BOOK', 'Books'),
    ('FOOD', 'Food & Drink');

-- +goose Down
DELETE FROM categories WHERE code IN ('ELEC','BOOK','FOOD');

$ goose up   # รอบ 1
2026/08/18 19:52:09 OK   20260818125159_create_categories_table.sql (16.95ms)
2026/08/18 19:52:09 OK   20260818125201_seed_categories.sql (2.68ms)
2026/08/18 19:52:09 goose: successfully migrated database to version: 20260818125201

$ goose up   # รอบ 2
2026/08/18 19:52:14 goose: no migrations to run. current version: 20260818125201

$ goose up   # รอบ 3
2026/08/18 19:52:14 goose: no migrations to run. current version: 20260818125201

$ psql -c 'SELECT count(*) FROM categories;'
 count
-------
     3
(1 row)

3 แถวเท่าเดิม — แต่เหตุผลไม่ใช่ที่คนส่วนใหญ่คิด
ไม่ใช่เพราะ SQL ฉลาด ไม่ใช่เพราะ UNIQUE constraint ดักไว้ (ถ้าเป็นแบบนั้นต้องมี error โผล่)
แต่เป็นเพราะ goose เห็นว่า version_id = 20260818125201 มีอยู่ในตารางแล้ว จึงไม่เปิดไฟล์นั้นอ่านด้วยซ้ำ

นี่คือคำตอบของหัวข้อ 1: สิ่งที่กันข้อมูลซ้ำคือ goose_db_version ไม่ใช่ตัว SQL
ซึ่งแปลว่าถ้าคุณเอา seed ไปวางในสคริปต์ที่รันทุกครั้งตอนแอป start (แบบเดียวกับ AutoMigrate) คุณต้องเขียน ON CONFLICT DO NOTHING เองทุกที่ ไม่งั้นข้อมูลบานทันที

9 · กับดัก 3 ข้อที่ทำ production พังจริง

กับดัก 1 — แก้ไฟล์ migration ที่ up ไปแล้ว

# สถานการณ์: seed_categories.sql ถูก up ไปแล้วเมื่อวาน (มี 3 แถวใน DB)
# วันนี้ PM ขอเพิ่ม category ใหม่ คุณเลยเปิดไฟล์เดิมมาเติมบรรทัด

-- +goose Up
INSERT INTO categories (code, name) VALUES
    ('ELEC', 'Electronics'),
    ('BOOK', 'Books'),
    ('FOOD', 'Food & Drink'),
    ('TOYS', 'Toys');        ← เพิ่มบรรทัดนี้เข้าไป

$ goose up
$ goose validate
$ psql -c 'SELECT * FROM categories;'

$ goose up
2026/08/18 19:52:24 goose: no migrations to run. current version: 20260818125201
EXIT=0

$ goose validate
EXIT=0

=== เครื่องคุณ (DB เดิม) ===
 id | code |     name
----+------+--------------
  1 | ELEC | Electronics
  2 | BOOK | Books
  3 | FOOD | Food & Drink
(3 rows)

=== เครื่องเพื่อน (DB เปล่า รันไฟล์ชุดเดียวกัน) ===
2026/08/18 19:52:34 OK   20260818125159_create_categories_table.sql (4.01ms)
2026/08/18 19:52:34 OK   20260818125201_seed_categories.sql (1.3ms)

 id | code |     name
----+------+--------------
  1 | ELEC | Electronics
  2 | BOOK | Books
  3 | FOOD | Food & Drink
  4 | TOYS | Toys
(4 rows)

กับดัก 2 — Down ที่ย้อน schema ได้ แต่ย้อนข้อมูลไม่ได้

ไฟล์นี้ดูสมมาตรสมบูรณ์แบบ ไม่มีอะไรน่าสงสัย:

-- +goose Up
ALTER TABLE products ADD COLUMN stock INTEGER NOT NULL DEFAULT 0;

-- +goose Down
ALTER TABLE products DROP COLUMN stock;

=== ข้อมูลก่อน down ===
 id |   name   | stock
----+----------+-------
  1 | Keyboard |    42
  2 | Mouse    |     7
(2 rows)

$ goose down
2026/08/18 19:51:29 OK   20260818125034_add_stock_to_products.sql (7.8ms)

$ goose up
2026/08/18 19:51:29 OK   20260818125034_add_stock_to_products.sql (2.59ms)
2026/08/18 19:51:29 OK   20260818125035_add_index_products_name.sql (2.44ms)
2026/08/18 19:51:29 goose: successfully migrated database to version: 20260818125035

=== ข้อมูลหลัง up ===
 id |   name   | stock
----+----------+-------
  1 | Keyboard |     0
  2 | Mouse    |     0
(2 rows)

ในทางปฏิบัติจึงมีกฎ 3 ข้อ:

กับดัก 3 — ลืมเขียน block Down

ถ้าไฟล์มีแต่ -- +goose Up แล้วสั่ง goose down คุณอาจคิดว่ามันจะฟ้อง — เปล่าเลย:

$ goose down
2026/08/18 19:53:29 EMPTY 20260818130000_no_annotation.sql (1.71ms)
EXIT=0

$ psql -c '\dt'
 public | goose_db_version | table | postgres
 public | t1               | table | postgres      ← ตารางยังอยู่!
(2 rows)

$ psql -c 'SELECT * FROM goose_db_version;'
 id | version_id | is_applied |           tstamp
----+------------+------------+----------------------------
  1 |          0 | t          | 2026-08-18 12:53:29.160615
(1 row)                                          ← แต่แถว version หายไปแล้ว

ตอนนี้ DB จริงกับ version table ไม่ตรงกัน — ตาราง t1 มีอยู่ แต่ goose คิดว่ายังไม่เคยสร้าง
พอสั่ง up เพื่อกู้สถานการณ์:

2026/08/18 19:53:36 goose run: ERROR 20260818130000_no_annotation.sql: failed to run SQL migration:
failed to execute SQL query "CREATE TABLE t1 (id int);": ERROR: relation "t1" already exists (SQLSTATE 42P07)
EXIT=1

ติดหล่มสมบูรณ์: up ก็พัง down ก็ไม่ช่วย ทางออกเดียวคือเข้าไป DROP TABLE t1; ด้วยมือ แล้วค่อย goose up ใหม่
→ เขียน Down เสมอ แม้จะเป็นแค่ DROP TABLE บรรทัดเดียว

โบนัส — ข่าวดีข้อเดียวของบทนี้

ถ้า migration พังกลางไฟล์ ไม่มีอะไรค้างครึ่ง ๆ กลาง ๆ
เพราะ goose ห่อทั้งไฟล์ไว้ใน transaction เดียว — คือมัดทุกคำสั่งในไฟล์เป็นชุดเดียว ถ้าพังคำสั่งใดคำสั่งหนึ่ง ให้ถือว่าทั้งชุดไม่เคยเกิดขึ้น
ในชุดนั้นมีทั้งคำสั่งที่เปลี่ยนโครงสร้าง (เรียกรวม ๆ ว่า DDL = คำสั่งกลุ่ม CREATE / ALTER / DROP) และการ INSERT ลง goose_db_version
แปลว่าถ้าพังกลางทาง Postgres จะย้อนคืนให้หมดทั้งชุด เหมือนไม่เคยรันเลย
ตอนที่ไฟล์ trigger พังเพราะลืม StatementBegin ผมเช็คทันทีหลังจากนั้น:

$ goose version
2026/08/18 19:51:44 goose: version 20260818125035     ← ยังอยู่ที่ไฟล์ก่อนหน้า

$ psql -c '\df'
                       List of functions
 Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)                                              ← function ไม่ถูกสร้างเลย

แก้ไฟล์แล้วรัน goose up ใหม่ได้เลย ไม่ต้องตามเก็บกวาดอะไร
แต่ข้อนี้เป็นจริงเฉพาะ Postgres (และ MySQL InnoDB) ที่ DDL อยู่ใน transaction ได้ — MySQL รุ่นที่ DDL auto-commit ห้ามเหมารวม

2026/08/18 19:55:42 goose run: ERROR 00002_concurrent_index.sql: failed to run SQL migration:
failed to execute SQL query "CREATE INDEX CONCURRENTLY idx_items_sku ON items (sku);":
ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block (SQLSTATE 25001)

10 · goose ทำสิ่งที่ AutoMigrate ทำไม่ได้ยังไง

ปิดวงกลับไปที่หัวข้อ 3 — ผมเอา DB ตัวเดียวกันที่ GORM สร้างไว้ มาให้ goose จัดการต่อ แล้วสั่งเปลี่ยนชื่อคอลัมน์ที่ AutoMigrate ทำไม่ได้:

-- 00001_rename_price_to_unit_price.sql
-- +goose Up
ALTER TABLE products RENAME COLUMN price TO unit_price;

-- +goose Down
ALTER TABLE products RENAME COLUMN unit_price TO price;

 id |   name   | price | cost
----+----------+-------+------
  1 | Keyboard |  1200 |
  2 | Mouse    |   590 |

 id |   name   | unit_price
----+----------+------------
  1 | Keyboard |       1200
  2 | Mouse    |        590

ไม่ใช่เพราะ goose ฉลาดกว่า — แต่เพราะ goose ให้คุณเขียน SQL เอง คุณเป็นคนเดียวที่รู้ว่า cost คือ price ที่เปลี่ยนชื่อ ไม่ใช่คอลัมน์ใหม่ และ goose แค่ทำให้ความรู้นั้นกลายเป็นไฟล์ที่รีวิวได้ · เก็บใน git ได้ · รันเหมือนกันทุกเครื่อง

ทดสอบความเข้าใจ

อ้างอิง

• pressly/goose — repo หลัก · หัวข้อ SQL Migrations คือที่ที่ error message ของ parser ชี้ไป
• goose documentation — รายการ command และ flag ทั้งหมด
• GORM — Migration — เอกสารที่ระบุเองว่า AutoMigrate จะไม่ลบคอลัมน์ที่ไม่ได้ใช้
• PostgreSQL — ALTER TABLE · CREATE INDEX (หัวข้อ CONCURRENTLY)
• PostgreSQL — Dollar-Quoted String Constants — ต้นเหตุที่ต้องมี StatementBegin