根据PostgreSQL文档，它们支持字符数据的3种数据类型：
字符可变（n），varchar（n）可变长度和限制
字符（n），字符（n）固定长度，空白填充
文本变量无限长
在我的应用程序中，我遇到了一些令人不快的情况，插入/更新查询失败，因为要插入的文本超过了varchar（n）或char（n）限制
对于这种情况，将这些列的数据类型更改为text就足够了
我的问题是：
- 如果我们概括并将每个字符存储列的数据类型更改为
text，那么在性能/内存方面是否有任何缺点 - 如果数据类型为
text的列每次存储10个或更少的字符，我应该选择text还是varchar（10） - 如果我选择
text有什么坏处
一般来说，就性能/内存而言，使用文本没有任何负面影响。相反：text是最佳选择。其他类型或多或少都有相关的缺点文本字面上是；“首选”；Postgres类型系统中字符串类型之间的类型，这可能会影响函数或运算符类型的解析
特别是，永远不要使用字符（n）（字符（n）的别名），除非您知道自己在做什么char或character只是character（1）的缩写，所以都一样。内部名称为bpchar（位于“空白填充字符”前面）。该类型仅用于与旧代码和标准兼容。如今，它毫无意义，浪费内存，并可能引发麻烦：
- 比较varchar和char
- Postgres SQL中的字符串字段长度
您可以将varchar（n）与长度修饰符（字符变化（n）的别名）一起使用。但是varchar（255）（255）没有特殊意义，也很少有意义
- 我应该为VARCHAR列添加任意长度限制吗
较旧版本在以后尝试更改varchar（n）的长度修饰符时会导致各种问题。在现代Postgres中，大多数问题都得到了缓解，但是没有长度说明符（以及检查约束）的）从未出现过这些问题text或varchar（字符变化的别名）
检查约束同样快速，并且不太可能在依赖于列类型的视图、函数、FK约束等方面引起问题。它可以做的不仅仅是强制执行最大字符长度——任何可以放入布尔表达式的内容。见：
- 更改视图中使用的PostgreSQL列
最后，还有”；char"（带双引号）：单个ASCII字母的1字节数据类型，用作廉价的内部枚举类型
对于Postgres中的字符数据，我很少使用text以外的任何东西