character varying(n)， varchar(n) -(两者相同)。值将被截断为n个字符而不引发错误。 character(n)， char(n) -(都是一样的)。固定长度，并将空白垫至长度结束。 文本-无限长度。

例子:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

我们得到了结果:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2

来自http://www.sqlines.com/postgresql/datatypes/text:的一个很好的解释

TEXT和VARCHAR(n)之间的唯一区别是您可以限制 VARCHAR列的最大长度，例如VARCHAR(255) 不允许插入长度超过255个字符的字符串。 TEXT和VARCHAR的上限都是1gb，但是没有 它们之间的性能差异(根据PostgreSQL 文档)。

有些OT:如果你使用Rails，网页的标准格式可能会有所不同。对于数据输入表单，文本框是可滚动的，但是字符变化(Rails字符串)框是一行的。显示视图根据需要而定。

如果你只使用文本类型，在使用AWS数据库迁移服务时可能会遇到问题:

使用大对象(LOB)，但目标LOB列不能为空

由于大型对象(lob)的大小未知且有时较大，因此需要更多的处理 和资源比标准对象。以帮助调整包含 lob, AWS DMS提供以下选项

如果你在所有事情上都坚持使用PostgreSQL，那么你可能没问题。但如果你打算通过ODBC或DMS等外部工具与你的db交互，你应该考虑不要事事使用TEXT。

没有区别，在引子里都是可变长度数组。

查看本文来自Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

以下是几个亮点:

总结一下: Char (n)——在处理小于n的值时占用太多空间(将它们填充到n)，并且由于添加尾随会导致微妙的错误 空格，加上改变极限是有问题的 Varchar (n) -在活动环境中更改限制是有问题的(在更改表时需要排他锁) Varchar -就像文本一样 Text -对我来说是胜过(n)数据类型的赢家，因为它没有数据类型的问题，胜过varchar -因为它有独特的名称

本文进行了详细的测试，以证明所有4种数据类型的插入和选择的性能是相似的。它还详细介绍了在需要时限制长度的其他方法。基于函数的约束或域提供了立即增加长度约束的优势，并且基于减少字符串长度约束的情况很少，depesz得出结论，它们中的一个通常是长度限制的最佳选择。

在我看来，varchar(n)有它自己的优点。是的，它们都使用相同的底层类型等等。但是，应该指出的是，PostgreSQL中的索引有其每行2712字节的大小限制。

TL;博士: 如果您使用无约束的文本类型，并且在这些列上有索引，则很可能在某些列上达到此限制，并在尝试插入数据时出错，但使用varchar(n)可以防止这种情况。

Some more details: The problem here is that PostgreSQL doesn't give any exceptions when creating indexes for text type or varchar(n) where n is greater than 2712. However, it will give error when a record with compressed size of greater than 2712 is tried to be inserted. It means that you can insert 100.000 character of string which is composed by repetitive characters easily because it will be compressed far below 2712 but you may not be able to insert some string with 4000 characters because the compressed size is greater than 2712 bytes. Using varchar(n) where n is not too much greater than 2712, you're safe from these errors.