sql – pgAdmin III错误行为?

前端之家收集整理的这篇文章主要介绍了sql – pgAdmin III错误行为?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在对pgAdmin进行查询,偶然发现了这种奇怪的行为.
我连接到运行Postgresql 9.1.9的服务器.
我有一个名为messages的表,其定义如下:
  1. ghareh@godot:~$psql
  2. psql (9.1.9)
  3. Type "help" for help.
  4.  
  5. ghareh=# \d messages
  6. Table "public.messages"
  7. Column | Type | Modifiers
  8. ---------------+-----------------------------+---------------------------------
  9. messageid | character varying(200) | not null
  10. senderaliasid | integer | not null
  11. referenceid | character varying(200) | default NULL::character varying
  12. recipaliasid | integer |
  13. datetime | timestamp(2) with time zone | not null
  14. subject | character varying(512) | not null
  15. body | text | not null
  16. listid | integer |
  17. Indexes:
  18. "messages_pkey" PRIMARY KEY,btree (messageid)
  19. "messages_datetime_idx" btree (datetime)
  20. "recipaliasid_idx" btree (recipaliasid)
  21. "referenceid_idx" btree (referenceid)
  22. "senderaliasid_idx" btree (senderaliasid)
  23. Foreign-key constraints:
  24. "messages_listid_fkey" FOREIGN KEY (listid) REFERENCES lists(listid)
  25. "messages_recip_fkey" FOREIGN KEY (recipaliasid,listid) REFERENCES aliases(aliasid,listid)
  26. "messages_sender_fkey" FOREIGN KEY (senderaliasid,listid)
  27. Referenced by:
  28. TABLE "messages_attachments" CONSTRAINT "pkfkmid" FOREIGN KEY (messageid) REFERENCES messages(messageid)

我的问题涉及专栏,正文和主题.

我有一个生成一组结果的查询.然后,为了优化我的查询,我添加了一个术语:where body就像’%JSON%’,即body的结构子集,其中body包含字符串’JSON’.
我得到了一些包含这个词的结果,有些则没有!但是,如果我搜索任意字符串,结果就可以了.我查了一下,发现查询不只是搜索正文列,还有主题列,这也很疯狂.

这是我的初步查询

  1. select * from messages where messageid = '44BC310F.1090305@torrez.us'

返回1行:

  1. messageid: "44BC310F.1090305@torrez.us";
  2. senderaliasid: 13777;
  3. referenceid: "7edfeeef0607171746r7d708067g15c77c3aa0ef9158@mail.gmail.com";
  4. recipaliasid: ;
  5. datetime: "2006-07-17 20:53:35-07";
  6. listid: 251;
  7. subject: "Re: svn commit: r422930 - /incubator/abdera/java/trunk/extensions/src/main/java/org/apache/abdera/ext/json/JSONWriter.java";
  8. body: "busted! thanks for the thorough review.
  9.  
  10.  
  11. -Elias
  12.  
  13. Garrett Rooney wrote:
  14. > On 7/17/06,eliast@apache.org <eliast@apache.org> wrote:
  15. >> Author: eliast
  16. >> Date: Mon Jul 17 17:44:10 2006
  17. >> New Revision: 422930
  18. >>
  19. >> URL: http://svn.apache.org/viewvc?rev=422930 (...)"

如果我搜索

  1. select * from messages
  2. where messageid = '44BC310F.1090305@torrez.us'
  3. and body like '%JSON%'

我不应该得到任何结果,因为身体里没有.但我仍然得到相同的行返回 – 这似乎是因为’JSON’在主题中?

我甚至试过这个:

  1. select * from messages
  2. where messageid = '44BC310F.1090305@torrez.us'
  3. and body like '%incubator/abdera/java/trunk/extensions/src/main/java/org/apache/abdera/ext/json/JSONWriter.java%'

而且我还有同样的一排.我非常困惑.

我试图在sqlfiddle.com上重现结果,但我没有成功.在那里,我得到了sql select查询的预期:
http://sqlfiddle.com/#!1/ec74c/4

解决方法

您无法在sql Fiddle上重现相同的效果.

我在Postgres 9.1.13(always upgrade to the latest point release!)中重新创建了表,并在pgAdmin(当前版本1.18.1)中运行了查询.我无法重现这个问题.

pgAdmin的?

我没有看到pgAdmin如何在这方面发挥作用 – 除非你只选择了一部分查询,否则不知道这种效果
pgAdmin shortcuts to execute scripts

或者您可能会被“每列最多字符数”设置所欺骗,该设置会截断显示中的长值,将匹配隐藏在截断的部分中,如@IMSoP suggested in his comment.检查文件 – >选项……

如果不是这样,除非我们处理你的问题中没有的拼写错误或情况,否则这表明你的数据库中存在某些问题.

腐败?

在只有一个损坏的索引的简单情况下,REINDEX TABLE可能会做到这一点:

  1. REINDEX TABLE messages;

但是,仔细看,我没有看到一个索引可能是这里的罪魁祸首.

系统目录损坏?首先阅读:
http://wiki.postgresql.org/wiki/Corruption

然后阅读Notes section for REINDEX并从shell运行:

  1. $export PGOPTIONS="-P"
  2. $psql broken_db
  3. ...
  4. broken_db=> REINDEX DATABASE broken_db;
  5. broken_db=> \q

腐败通常表明您的硬件存在问题.失败的磁盘或其他东西.跟进……

相关问题:
Repair Corrupt database postgresql

猜你在找的MsSQL相关文章