PostgreSQL LIKE 大小寫實(shí)例
PostgreSQL 數(shù)據(jù)庫
函數(shù)upper(“字符串”):轉(zhuǎn)成大寫字符串
WHERE UPPER("User_Name") LIKE upper(username)
此句查詢“User_Name”
中值大小寫不區(qū)分。
SELECT "User_Id","User_Image","User_Name","User_Birthday","User_Sex","User_OnlineLat","User_OnlineLon","User_State", (SELECT COUNT(*) FROM "tbUsers" WHERE UPPER("User_Name") LIKE upper(username)) AS "user_count" FROM "tbUsers" WHERE UPPER("User_Name") LIKE upper(username) LIMIT 10 OFFSET 0;
補(bǔ)充:PostgreSQL數(shù)據(jù)庫表名大小寫問題
今天,用Delphi 連接postgresql數(shù)據(jù)庫時(shí),出現(xiàn)了問題。問題提示:error:表不存在。Postgrsql數(shù)據(jù)庫的表名都用大寫,比如Users、Profiles、Money等。
多嘗試了一些表,發(fā)現(xiàn)當(dāng)表名都是小寫時(shí),可以連接。
后來發(fā)現(xiàn),在做select * from Users這樣的查詢的時(shí)候也會(huì)提示ERROR: relation “users” does not exist。
分析了一下,由于 PostgreSQL 是大小寫敏感的,并默認(rèn)對SQL語句中的數(shù)據(jù)庫對象名稱轉(zhuǎn)換為小寫,因此如果你在創(chuàng)建數(shù)據(jù)庫對象時(shí)指定了大小寫混和的對象名稱,那么在通過SQL語句訪問 這些對象時(shí),由于Postgresql數(shù)據(jù)庫里表名應(yīng)該是分大小寫的,導(dǎo)致找不到users這個(gè)表。
要解決這個(gè)問題,必須使用雙引號(”)將數(shù)據(jù)庫對象括起來,以提示 PostgreSQL 不用幫你轉(zhuǎn)換對象名為小寫,否則將激發(fā)“xxxxx對象不存在”的異常,譬如您的數(shù)據(jù)庫中有名為 TUser 的表,您在 PostgreSQL 自帶的圖形化查詢工具中必須使用類似這樣的查詢語句才能正確執(zhí)行:SELECT * FROM “TUser”,當(dāng)然它對 SQL 標(biāo)準(zhǔn)中的保留字和關(guān)鍵字是不區(qū)分大小寫的,所以寫成 select * From “TUser” 這樣也是完全可以的。
另外,PostgreSQL 對數(shù)據(jù)也是大小寫敏感的,這點(diǎn)與 SQLServer 不同(SQLServer 默認(rèn)是不敏感的),譬如在 TUser 表中有字段 Name,其中有一行 Name 字段值為“Tony Tang”的記錄,如果直接使用
SELECT * FROM “TUser” WHERE “Name” LIKE ‘%tony%';
是查詢不到這條記錄的,不過你可以這么寫:
SELECT * FROM “TUser” WHERE UPPER(“Name”) LIKE ‘%TONY%';
呵呵,是不是覺得這樣不太好看,而且擔(dān)心性能會(huì)受影響?幸好 PostgreSQL 提供了關(guān)鍵字 ILIKE 來幫我們解決這個(gè)問題,這真是個(gè)非常有趣的關(guān)鍵字(I like),對于第一種寫法只需要將 LIKE 替換成 ILIKE 就可以了。
最簡單的辦法,就是數(shù)據(jù)庫里所有的表名都是小寫的,最好字段名也都是小寫的(因?yàn)橛成涞綄ο髮傩砸院蠡旧蠒?huì)變換大小寫,JPA是都變成小寫)。這樣就沒與那么多煩惱以及兼容性問題了。
小結(jié):
1、PostgreSQL對表名、字段名都是區(qū)分大小寫的。用SQL語句的時(shí)候需要加雙引號。
2、PostgreSQL在SQL語句中對數(shù)據(jù)(字段)大小寫是敏感的.
select login_ID as 編號, name as 用戶名 from t_login(這種會(huì)報(bào)錯(cuò),找不到login_ID字段).
如果要查詢大寫字母的字段,同樣要加上雙引號:select “l(fā)ogin_ID” as 編號, name as 用戶名 from t_login.
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教。
相關(guān)文章
postgresql數(shù)據(jù)庫表ID自增的實(shí)現(xiàn)代碼
postgresql數(shù)據(jù)庫可以創(chuàng)建主鍵,但是沒有像mysql那樣直接指定主鍵自增的auto_increment關(guān)鍵字,因此如果在postgresql中創(chuàng)建表指定主鍵自增使用auto_increment會(huì)報(bào)錯(cuò),本文通過一個(gè)實(shí)例給大家演示自增ID的實(shí)現(xiàn),需要的朋友可以參考下2023-12-12postgresql 實(shí)現(xiàn)查詢出的數(shù)據(jù)為空,則設(shè)為0的操作
這篇文章主要介紹了postgresql 實(shí)現(xiàn)查詢出的數(shù)據(jù)為空,則設(shè)為0的操作,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明
這篇文章主要介紹了postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-12-12PostgreSQL 禁用全表掃描的實(shí)現(xiàn)
這篇文章主要介紹了PostgreSQL 禁用全表掃描的實(shí)現(xiàn)操作,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01基于PostgreSQL/openGauss?的分布式數(shù)據(jù)庫解決方案
ShardingSphere-Proxy?作為透明數(shù)據(jù)庫代理,用戶無需關(guān)心?Proxy?如何協(xié)調(diào)背后的數(shù)據(jù)庫。今天通過本文給大家介紹基于PostgreSQL/openGauss?的分布式數(shù)據(jù)庫解決方案,感興趣的朋友跟隨小編一起看看吧2021-12-12PostgreSQL時(shí)間相差天數(shù)代碼實(shí)例
PostgreSQL是一款簡介而又性能強(qiáng)大的數(shù)據(jù)庫應(yīng)用程序,其在日期時(shí)間數(shù)據(jù)方面所支持的功能也都非常給力,這篇文章主要給大家介紹了關(guān)于PostgreSQL時(shí)間相差天數(shù)的相關(guān)資料,需要的朋友可以參考下2023-11-11使用postgresql獲取當(dāng)前或某一時(shí)間段的年月日
這篇文章主要給大家介紹了關(guān)于使用postgresql獲取當(dāng)前或某一時(shí)間段的年月日的相關(guān)資料,在PostgreSQL中可以使用函數(shù) NOW() 來查詢當(dāng)前時(shí)間,文中通過代碼示例介紹的非常詳細(xì),需要的朋友可以參考下2023-07-07