【问题标题】:Postgresql support for national character data typesPostgresql 对国家字符数据类型的支持
【发布时间】:2019-12-30 03:59:38
【问题描述】:

寻找讨论 PostgreSQL 对 NATIONAL CHARACTER 数据类型集支持的参考资料。例如此查询运行没有错误:

select cast('foo' as national character varying(10))

但文档似乎没有讨论该类型 Postgres character data types

Postgres 实现这些与 CHARACTER 数据类型不同吗?也就是说,NATIONAL 关键字如何影响数据的存储或表示方式?

有人可以分享一个或两个链接到我似乎找不到的任何参考资料吗? (除了不久前的一些邮件列表通信)

【问题讨论】:

  • PostgreSQL 中没有“国家字符”这样的概念。简而言之:有数据库范围的设置(当您创建新数据库时):postgresql.org/docs/current/sql-createdatabase.html - 查看encodinglc_collatelc_ctype 选项;和“整理”:postgresql.org/docs/current/collation.html 老实说,我没有对此进行很多试验,因为使用UTF8 编码对于我从事的所有项目来说已经足够了。
  • 是的,我明白了。只是好奇编译器接受 NATIONAL 关键字。我想这只是为了兼容性,并没有什么特别之处。
  • 顺便说一句,这种问题在姊妹站可能会做得更好:dba.stackexchange.com

标签: postgresql sqldatatypes


【解决方案1】:

如果您在 PostgresSQL 中请求national character varying,您将得到一个常规的character varying

PostgreSQL 对普通字符和国家字符使用相同的编码。

“国家字符”是旧时代的遗留物,当时人们仍然使用像 LATIN-1 这样的单字节编码,并且需要对不适合的字符使用不同的编码。

PostgreSQL 一直支持 UNICODE 编码,所以这不是问题。只需确保您没有指定默认 UTF8 以外的编码。

【讨论】:

    【解决方案2】:

    NATIONAL CHARACTER 在 SQL:92 标准(第 4.2.1 节)中没有真正的意义,只是说它的意思是“特定的实现定义的字符库”。如果您感到惊讶,请不要。 SQL 标准有很多棘手的方面。

    至于 Postgres 中的文本处理,您可能有兴趣了解:

    见:

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-02-27
      • 1970-01-01
      • 2011-04-23
      相关资源
      最近更新 更多