對(duì)于上下文，這個(gè)問題發(fā)生在我使用默認(rèn) postgres 數(shù)據(jù)庫驅(qū)動(dòng)程序編寫的 Go 程序中。我一直在構(gòu)建一個(gè)服務(wù)來與一個(gè) postgres 數(shù)據(jù)庫對(duì)話，該數(shù)據(jù)庫有一個(gè)類似于下面列出的表：CREATE TABLE object (    id SERIAL PRIMARY KEY NOT NULL,    name VARCHAR(255) UNIQUE,    some_other_id BIGINT UNIQUE    ...);我為這個(gè)項(xiàng)目創(chuàng)建了一些端點(diǎn)，包括一個(gè)“安裝”端點(diǎn)，它有效地充當(dāng)了一個(gè) upsert 函數(shù)，如下所示：INSERT INTO object (name, some_other_id)VALUES ($1, $2)ON CONFLICT name DO UPDATE SET    some_other_id = COALESCE(NULLIF($2, 0), object.some_other_id)我還有一個(gè)帶有如下基礎(chǔ)查詢的“更新”端點(diǎn)：UPDATE objectSET some_other_id = COALESCE(NULLIF($2, 0), object.some_other_id)WHERE name = $1問題：每當(dāng)我運(yùn)行更新查詢時(shí)，我總是遇到錯(cuò)誤，引用字段“some_other_id”：pq：值“1010101010144”超出整數(shù)類型的范圍但是，即使該行已經(jīng)存在于數(shù)據(jù)庫中（當(dāng)它必須評(píng)估 COALESCE 語句時(shí)），此錯(cuò)誤也不會(huì)發(fā)生在查詢的“upsert”版本上。通過將 COALESCE 語句更新為如下所示，我已經(jīng)能夠防止此錯(cuò)誤：COALESCE(NULLIF($2, CAST(0 AS BIGINT)), object.some_other_id)但由于第一次查詢從未發(fā)生過這種情況，我想知道這種不一致是否來自我做錯(cuò)了什么或我不明白的事情？還有最好的做法是什么，我應(yīng)該鑄造所有的價(jià)值觀嗎？我肯定將一個(gè) 64 位整數(shù)傳遞給“some_other_id”的查詢，即使沒有顯式類型轉(zhuǎn)換，第一個(gè)查詢也適用于 Go 實(shí)現(xiàn)。如果需要更多信息（或 Go 實(shí)現(xiàn)），請(qǐng)告訴我，非常感謝?。ǎ壕庉嫞簽榱讼煜?，查詢直接在 Go 代碼中執(zhí)行，如下所示：res, err := s.db.ExecContext(ctx, `UPDATE object SET some_other_id = COALESCE(NULLIF($2, 0), object.some_other_id) WHERE name = $1`,    "a name",    1010101010144,)兩個(gè)查詢都以完全相同的方式執(zhí)行。編輯：還在我當(dāng)前的解決方法中更正了參數(shù)（從$51到$2）。我還想借此機(jī)會(huì)指出，該查詢確實(shí)適用于我提出的修復(fù)，這表明問題在于我將 postgres 與NULLIF語句中的類型混淆了？在我的代碼和數(shù)據(jù)庫之間沒有存儲(chǔ)過程要求一個(gè)INTEGERarg，至少我已經(jīng)寫過。