PostgreSQL命名约定是一种用于表字段名称的命名规范。这个问题的出现是因为对于字段命名的规范并没有明确的指导方针或样式指南，导致开发者对于如何命名字段存在疑惑。为了解决这个问题，有人提出了一些现代化的命名约定。

根据提供的信息，最好的做法是使用与项目代码相同的命名规范。例如，在使用JavaScript等面向对象编程语言时，表名应该使用PascalCase，而属性名应该使用camelCase。而如果采用函数式编程方法，它们都应该使用camelCase命名。此外，按照约定，JavaScript类应该使用PascalCase，属性应该使用camelCase，所以这种命名方式也是合理的。

另一方面，如果你在Python中使用SqlAlchemy进行编码，那么使用snake_case命名函数派生模型，使用PascalCase命名类派生模型是有道理的。在这两种情况下，属性/列应该使用snake_case命名。这是因为Python社区普遍接受了snake_case作为命名约定。

由于缺乏明确的指导方针，开发者可以根据项目的编程语言和约定来选择合适的命名方式。这样可以提高代码的可读性和一致性，并减少不必要的混乱。

在PostgreSQL中，表字段名称的命名约定是一个常见的问题。由于缺乏统一的风格或标准，所以并没有一个正式的手册。只要你理解了标识符命名的规则，你可以使用任何你喜欢的方式进行命名。

实际上，我发现使用lower_case_underscore_separated_identifiers更容易，因为不需要在每个地方都使用“Double Quote”来保留大小写、空格等。

如果你想将你的表和函数命名为“ṕṕ! "betty" Shard$42”，你完全可以这样做，尽管在各个地方输入这个名称可能会很麻烦。

主要需要了解的几点是：

- 除非加上双引号，否则标识符会被转换为小写，所以MyTable、MYTABLE和mytable都是相同的，但"MYTABLE"和"MyTable"是不同的。

- 除非加上双引号：

- SQL标识符和关键字必须以字母（a-z，还包括带有变音符号和非拉丁字母的字母）或下划线(_)开头。标识符或关键字的后续字符可以是字母、下划线、数字（0-9）或美元符号($)。

- 如果你想将关键字用作标识符，你必须要使用双引号将其括起来。

实际上，我强烈建议您不要将关键字用作标识符，至少要避免使用保留字。仅仅因为你可以将一个表命名为"with"并不意味着你应该这样做。

总结一下，为了避免命名约定的问题，我建议使用lower_case_underscore_separated_identifiers来命名字段。这样做可以避免在各个地方都添加双引号。

感谢您提供了关于标识符命名规则的文档链接。我之前在找到这个特定主题时遇到了困难。

最近，我听说将lower_case_underscore_separated_identifiers命名方式称为"snake case"，我觉得这样命名更容易理解和识别。

PostgreSQL字段命名的约定是指数据库表字段的命名规则。一般来说，SQL关键字使用大写，而标识符（数据库、表、列等的名称）使用小写加下划线的形式。这是一种普遍的约定，也是强烈推荐使用的规范。

在PostgreSQL中，当标识符未加引号时，它们是不区分大小写的，实际上在内部将它们转换为小写。只有在加引号时，标识符才是区分大小写的。很多人对这个特性并不了解，因此使用全部小写的标识符是安全的。当然，也可以使用camelCase、PascalCase或UPPER_CASE的命名方式，只要保持一致：要么始终加引号，要么从不加引号（这包括模式的创建）。

关于其他约定或风格指南，我不太了解。通常，使用序列（通常使用serial宏）创建代理键，如果手动创建序列，最好遵循相应的命名规范（tablename_colname_seq）。

关于引用数据类型和引用函数是否有约定使用大写或小写，我猜我们将类型和函数视为标识符，因此使用小写。

值得一提的是，PostgreSQL 10引入了identity列作为serial的符合SQL标准的替代品。

作为PostgreSQL的新用户，这让人非常沮丧。要么一直加引号，要么使用丑陋的命名约定，这两种选择都很糟糕。

这种约定并不丑陋，而且请阅读上面Craig的评论。如果在创建表时没有加引号，那么在编写查询时就不需要加引号（也就是保持一致性）。

如果在创建表时不加引号，PostgreSQL会将表名和字段名转换为小写。在编写查询时可以使用驼峰命名法，但查询结果将显示为全部小写，这在字段由多个单词组成时很难阅读（例如lastupdateddate）。如果希望查询结果中的列名可读性好，必须要么全部加引号，要么使用蛇形命名法，而这种方式在我看来是丑陋的。如果PostgreSQL保持原样并且不需要引号就能正常工作，那将更好。

这是SQL标准的规定。关键字是不区分大小写的。

我讨厌使用大写的关键字，真的很讨厌，不管有没有约定。关键字与大小写无关。我更喜欢全部小写。是的，我知道这只是个人偏好，但这也只是一个评论而已。

他们又拿出了这个老掉牙的约定。camelCase和PascalCase更清晰，不需要我到处添加不必要的下划线。更糟糕的是，实际上没有办法绕过这个约定。如果我提供的大小写能被保留就好了。嗯，这就是现实。