如何防止不同的連接對同一查詢中的 bytea 進行不同的處理?
我發現兩個不同客戶端發出的相同 postgresql 查詢的處理方式不同。具體來說,bytea 值的插入方式不同。
展示該行為的查詢是這樣的:
INSERT INTO "TestTable" ("Input") VALUES (decode('74657374', 'hex'))
74657374 是十六進制的“測試”。在一個客戶端中,“測試”被插入到“輸入”欄位中,無論該欄位是 text/varchar 還是 bytea。這就是我想要的行為。在另一個客戶端中,’\x74657374’ 被插入到“輸入”欄位中,無論是 text/varchar 還是 bytea。此字元串是 ASCII ’test’ 的 bytea 字節的 postgresql 文字表示。但是插入了 sql 文字語法本身。我不希望這種行為。
我使用了一段手寫的 SQL,bytea 值只出現在查詢“內部”(如果“輸入”列的類型為 Text,那麼文字和接收列都沒有 bytea 類型),在我看來不太可能任一客戶端正在解析然後重建查詢。因此,似乎差異必鬚髮生在執行查詢的伺服器上。這意味著必須有一些特定於連接的配置設置正在改變伺服器行為。
誰能告訴我哪些連接特定設置可能會改變這種行為?
我知道查詢的行為確實不同,這不是顯示問題等,因為我可以看到同一個表中的行具有不同的值(’test’ 和 ‘\x74657374’)。我嘗試了各種替代 bytea 處理方法,但它們都受到這個問題的影響。對於那些感興趣的人,“好”客戶端是 pgAdminIII,“壞”客戶端是 Ruby PG gem。儘管出於我上面給出的原因,我相信 postgresql 必須有一些內置功能支持這種行為。
我懷疑不同之處在於 a 的外觀
bytea
取決於目前的設置bytea_output
:CREATE TABLE test (id integer PRIMARY KEY, t text, b bytea); SHOW bytea_output; bytea_output -------------- hex (1 row) INSERT INTO test VALUES (1, decode('74657374', 'hex'), decode('74657374', 'hex')); TABLE test; id | t | b ----+------------+------------ 1 | \x74657374 | \x74657374 (1 row) SET bytea_output = 'escape'; TABLE test; id | t | b ----+------------+------ 1 | \x74657374 | test (1 row) INSERT INTO test VALUES (2, decode('74657374', 'hex'), decode('74657374', 'hex')); TABLE test; id | t | b ----+------------+------ 1 | \x74657374 | test 2 | test | test (2 rows) RESET bytea_output; TABLE test; id | t | b ----+------------+------------ 1 | \x74657374 | \x74657374 2 | test | \x74657374 (2 rows)
該
text
列實際上包含從bytea
to類型轉換的結果text
,這取決於 的目前設置bytea_output
。該
bytea
列包含正確的四個字節,但顯示方式不同,具體取決於 的目前設置bytea_output
。