Postgres 和 bytea 列看起来很奇怪答案

【问题标题】：Postgres and bytea columns appearing weirdPostgres 和 bytea 列看起来很奇怪
【发布时间】：2021-04-05 01:51:39
【问题描述】：

我转储了一个数据库并将其导入到不同的服务器中。其中一个表有一个 bytea 列，并且有单行数据。在原始服务器上，如果我 SELECT * FROM users;，它会显示正确的值 @. - 但是，当我在第二台服务器上执行相同的选择语句时，我会为同一字段得到 \x402e。我试图把我的头绕在这个列类型上，但它在我的头上。为什么它会在一台服务器上显示为转义字符串，而在另一台服务器上却不显示？两台服务器都在运行 Pg11，我正在通过 psql 访问它们。

原始服务器：

=# \d+ users
                                                         Table "public.users"
  Column   |          Type          | Collation | Nullable |              Default              | Storage  | Stats target | Description 
-----------+------------------------+-----------+----------+-----------------------------------+----------+--------------+-------------
 id        | integer                |           | not null | nextval('users_id_seq'::regclass) | plain    |              | 
 priority  | integer                |           | not null | 7                                 | plain    |              | 
 policy_id | integer                |           | not null | 1                                 | plain    |              | 
 email     | bytea                  |           | not null |                                   | extended |              | 
 fullname  | character varying(255) |           |          | NULL::character varying           | extended |              |

=# SELECT * FROM users;
 id | priority | policy_id | email | fullname 
----+----------+-----------+-------+----------
  1 |        0 |         1 | @.    | 
(1 row)

辅助服务器：

=> \d+ users
                                                         Table "public.users"
  Column   |          Type          | Collation | Nullable |              Default              | Storage  | Stats target | Description 
-----------+------------------------+-----------+----------+-----------------------------------+----------+--------------+-------------
 id        | integer                |           | not null | nextval('users_id_seq'::regclass) | plain    |              | 
 priority  | integer                |           | not null | 7                                 | plain    |              | 
 policy_id | integer                |           | not null | 1                                 | plain    |              | 
 email     | bytea                  |           | not null |                                   | extended |              | 
 fullname  | character varying(255) |           |          | NULL::character varying           | extended |              |

=> SELECT * FROM users;
 id | priority | policy_id | email  | fullname 
----+----------+-----------+--------+----------
  4 |        0 |         1 | \x402e | 
(1 row)

【问题讨论】：

为什么要将电子邮件地址存储在bytea 列中？一开始那是没有意义的。电子邮件不是“二进制值”——它是text 值。我有点惊讶您的“原始”服务器会以文本开头显示bytea 列。但可能您导出和导入数据的方式是造成这种情况的原因 - 但您甚至没有告诉我们您是如何做到的。
@a_horse_with_no_name - 这是 Amavis 提供的架构 - 根据他们的文档，它符合 RFC 2821。请参阅此处的第 4 段：ijs.si/software/amavisd/README.sql-pg.txt
我使用没有参数的基本 pg_dump 命令导出了数据库。我通过粘贴到 psql shell 中“导入”了。
好吧，我不会遵循该链接中的建议。显然，写这篇文章的人并没有真正使用 Postgres 的经验。 “此外，字段 mail_id 和 secret_id 应区分大小写，因此应避免数据类型 char 或 varchar” - 这是完全错误的。 varchar 或 text 区分大小写。并且建议使用char(x) 而不是正确的boolean 列也是相当值得怀疑的。说真的：使用text 作为电子邮件列（正确使用boolean 列作为是/否标志）
我可以更改电子邮件列，但不能更改 Y/N 列，因为它们是 Amavis 软件中的预期值。当我第一次看到这个架构时，我也有同样的想法。

标签： postgresql bytea

【解决方案1】：

set bytea_output to hex; 
select '@.'::bytea;

┌────────┐
│ bytea  │
├────────┤
│ \x402e │
└────────┘

set bytea_output to escape; 
select '@.'::bytea;

┌───────┐
│ bytea │
├───────┤
│ @.    │
└───────┘

您的服务器上似乎有不同的设置。

Documentation

【讨论】：