postgres表名，字段名大小写的区别

以你之姓@ 2023-01-01 08:51 177阅读 0赞

[https://blog.csdn.net/zhanghui3239619/article/details/103195600][https_blog.csdn.net_zhanghui3239619_article_details_103195600]

[https://www.cnblogs.com/ficow/p/6612484.html][https_www.cnblogs.com_ficow_p_6612484.html]

[https://www.jianshu.com/p/25f7e7c653d0][https_www.jianshu.com_p_25f7e7c653d0]

[https://www.cnblogs.com/gaofan/p/11398753.html][https_www.cnblogs.com_gaofan_p_11398753.html]

[https://www.cnblogs.com/browsepearls/p/11445019.html][https_www.cnblogs.com_browsepearls_p_11445019.html]

# [PostgreSQL之大小写][https_www.cnblogs.com_browsepearls_p_11445019.html] #

1. PostgreSQL的数据库内核对大小写敏感。数据库名，数据表名，列名区分大小写。

2. 在PostgreSQL中，执行SQL语句时，会把所有表示关键字，库名，表名，列名的字符串转换成小写。所以又说PostgreSQL不区分大小写的。

3. 在书写SQL时，为了便于理解，默认：关键字大写，表名首字母大写，列名全部小写。

示例：

CREATE DATABASE Contact;    /\*存在一个名字叫contact的数据库，不存在Contact数据库\*/

CREATE DATABASE contact;   /\*报错，数据库contact已经存在\*/

CREATE DATABASE "Contact"  /\*ok,加双引号告诉PostgreSQL，不要转换成小写\*/

总结：

一.对象名：如库名，表名，字段名  
数据库内核是区分大小写的。  
只是为了方便使用，数据库在分析SQL脚本时，对不加双引号的所有对象名转化为小写字母。  
除非你在对象名加上双引号。  
所以  
1。从建表到应用，要么都加双引号，要么都不要加。  
2。如果以上这点做不到，所有的对象名给我写小写字母。  
3. 字符串要用单引号括起来，双引号用来明确告诉数据库不要转换成小写，本次要区分大小写。  
二.数据  
区分大小写  
假如LIKE '%a%' ,别指望A会出来

**所以这里就可以得出以下结论：**

当你要创建的表的表名是需要大写的，那你就用双引号""括起来；

以后只要是和这个表有关的操作，都要用""把表名给括起来，注意是英文状态的双引号！

[https://blog.csdn.net/zhanghui3239619/article/details/103195600][https_blog.csdn.net_zhanghui3239619_article_details_103195600]

# postgres查询自动将大写的名称转换为小写 #

![426136e8363e68fc321f3d3551b0d579.png][]

[pigs2018][] 2019-11-22 10:01:31 ![11d4e66b47a786d7307438a15382d44a.png][] 1642 ![50c7c045de1e4400c6f27a33ed55cf7c.png][] 收藏

分类专栏： [数据库][Link 1]

版权

1.  `SELECT sum(aa) as "recordNumber" FROM table`
2.  `SELECT sum(aa) as recordNumber FROM table`

postgis查询字段是将字段字段转为小写，如果需要大写的字符，需要加双引号

[https://www.jianshu.com/p/25f7e7c653d0][https_www.jianshu.com_p_25f7e7c653d0]

# postgresql大小写的问题 #

[厚土火烟][Link 2]关注

2017.09.09 18:22:08字数 288阅读 5,190

使用 postgresql ，如果字段名有大写，结果就会很糟糕。数据库 SQL 不识别大写，全部被识别成小写了。  
但是，很奇葩，在给字段起名的时候，大小写是区分的。  
比如，你可以在同一张表里分别设定两个字段为 userName 和 username，postgresql 是认可的。但是，写 SQL 的时候就有问题了。它会一直反馈说  
错误: 字段 "username" 被指定多次  
更糟糕的是，如果你把小写的 username 删除，userName它还是不识别。它会反馈说 "username" 字段不存在  
也就是说，你虽然在字段中成功写入了大写字母，但是 postgresql 永远都不认识它们。  
字段是这样，表名也是这样。  
我想说 SAD.  
不仅如此，使用 postgresql 还要注意不能使用它的关键字做为表名什么的。比如 user 就是不行的。

--------------------

其实，postgresql 对大写还是支持的，只是，你需要在这些大写的字段上加上**双引号**。

insert into cofox (username, userinfo, "userName") values (4, 5, 6)
    insert into cofox (username, userinfo, "userName") values ('吃','饭','啦')

3人点赞

[随笔][Link 3]

[https://www.cnblogs.com/gaofan/p/11398753.html][https_www.cnblogs.com_gaofan_p_11398753.html]

# [PostgreSQL大小写的坑][https_www.cnblogs.com_gaofan_p_11398753.html] #

前景：之前听前辈们说过postgresql大小写敏感，觉得自己注意应该也不是啥事。今天用postgresql写存储过程，以前的命名习惯，喜欢全大写，然后调用的存储过程名写的大写也提示找不到，然后开始试验了下表名、字段、函数等名大写或驼峰命名，发现postgresql的大小写规则可以用“混乱”形容。当然“混乱”不是指postgresql没定义清楚，是指我这程序员的思维理解起来不那么舒服。

Part1:试验了各种大小写以及调用后的现象

1）建立了大写的表NODE，查询不论是用NODE还是node都不行，需用"NODE"才可识别。

正确语句：

SELECT * from  "NODE" ;

2）建立了小写的表edge，查询不论是用EDGE还是edge都可以(额，说好的大小写敏感呢)，"edge"也可识别。

正确语句：

SELECT * from edge ;或 EDGE 或"edge"

3）存储过程测试结论与表名一样。

大写的存储过程TP\_INSERT需用call "TP\_INSERT"（）；来调用。

小写的存储过程tp\_select,可用call  tp\_select(); 或 call TP\_SELECT();或call  "tp\_select"(); 来调用

4）在NODE表中建立字符型name,Name,NAME三个字段(居然能建成功)，对应插入值'lili','Lili','LILI'。

INSERT INTO public."NODE"(name, "Name", "NAME")  VALUES ('lili','Lili', 'LILI');   //插入成功
    
     SELECT  name,"Name","NAME" from "NODE"; //查询正确返回值

小写表的测试结果与上述结果相同。

Part2：结论

1）PostgreSQL对建立的对象（存储过程、函数、表、字段、序列等）名称的大小写敏感；

2）SQL语句中大小写不敏感，大写和小写的sql语句意义一致,所有大写的均转换为小写来解释，如select \* from NODE和select \* from node是完全一致的；

3）如要查询或调用大写的PostgreSQL对象，需在对应的名称上加双引号，如"NODE"；

4）最后的建议就是PostgreSQL中能用小写的就小写，毕竟"NODE"这种加双引号的写法总感觉怪怪的。

作者： [GoodGF][]

出处： [https://www.cnblogs.com/gaofan/][GoodGF]

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

分类: [Postgres][]

标签: [postgres][], [大小写][Link 4]

[https_blog.csdn.net_zhanghui3239619_article_details_103195600]: https://blog.csdn.net/zhanghui3239619/article/details/103195600
[https_www.cnblogs.com_ficow_p_6612484.html]: https://www.cnblogs.com/ficow/p/6612484.html
[https_www.jianshu.com_p_25f7e7c653d0]: https://www.jianshu.com/p/25f7e7c653d0
[https_www.cnblogs.com_gaofan_p_11398753.html]: https://www.cnblogs.com/gaofan/p/11398753.html
[https_www.cnblogs.com_browsepearls_p_11445019.html]: https://www.cnblogs.com/browsepearls/p/11445019.html
[426136e8363e68fc321f3d3551b0d579.png]: /images/20221120/00029fc9cff24d5186edb601bdafac85.png
[pigs2018]: https://blog.csdn.net/ZHANGHUI3239619
[11d4e66b47a786d7307438a15382d44a.png]: https://img-blog.csdnimg.cn/img_convert/11d4e66b47a786d7307438a15382d44a.png
[50c7c045de1e4400c6f27a33ed55cf7c.png]: /images/20221120/b4ac72517ebb4d399513600d2f3b5b98.png
[Link 1]: https://blog.csdn.net/zhanghui3239619/category_7333512.html
[Link 2]: https://www.jianshu.com/u/bc9204c0cb70
[Link 3]: https://www.jianshu.com/nb/13724864
[GoodGF]: https://www.cnblogs.com/gaofan/
[Postgres]: https://www.cnblogs.com/gaofan/category/1504095.html
[postgres]: https://www.cnblogs.com/gaofan/tag/postgres/
[Link 4]: https://www.cnblogs.com/gaofan/tag/%E5%A4%A7%E5%B0%8F%E5%86%99/