語境通過一致性檢查，我的意思是消除肯定不會(huì)返回任何內(nèi)容的查詢。例如：考慮表boxes，其中可用列之一是color CHAR(6)；用戶通過與前端的交互發(fā)送該字符串'abcdefg'以針對(duì)列進(jìn)行查詢；color然后，后端將SELECT * FROM boxes WHERE color = ?使用上面提到的相同字符串執(zhí)行類似于 的查詢；至少在我的 PostgreSQL 安裝中，我可以執(zhí)行這個(gè)查詢，即使知道它永遠(yuǎn)不會(huì)返回任何內(nèi)容（長(zhǎng)度為'abcdefg'7）。目前，前端和后端都會(huì)在從數(shù)據(jù)庫(kù)訪問數(shù)據(jù)之前執(zhí)行一致性檢查（以避免不必要的調(diào)用）。事實(shí)上，前端的設(shè)計(jì)就是為了禁止用戶請(qǐng)求無效的查詢。但假設(shè)沒有進(jìn)行這些檢查，尤其是在后端，這對(duì)應(yīng)用程序有多重要？問題PostgreSQL 如何處理這些查詢，它是否有任何類型的算法在執(zhí)行此類查詢時(shí)立即不返回任何內(nèi)容？或者不調(diào)用數(shù)據(jù)庫(kù)而只向用戶發(fā)送類似not found或 的內(nèi)容會(huì)更好嗎invalid request？進(jìn)一步的背景我們已經(jīng)清理了從前端接口獲取的所有輸入，因此這不是關(guān)于執(zhí)行這些檢查后獲得的安全性可能帶來的好處/壞處的問題。我們后端使用的語言是 Go，我相信它在定期執(zhí)行這些檢查（即在大多數(shù) HTTP 請(qǐng)求上）時(shí)沒有問題。PS：我知道你可以在 PostgreSQL 中將十六進(jìn)制轉(zhuǎn)換為整數(shù)，這只是一個(gè)假設(shè)的問題，我用它來簡(jiǎn)化對(duì)問題的理解（我希望它能做到）。