Parethesis don't work correctly in where clause
От | Casey Allen Shobe |
---|---|
Тема | Parethesis don't work correctly in where clause |
Дата | |
Msg-id | 1720D5C9CF7AD411B30700010226ECC90832C3F6@atlexchange.internal.secureworks.net обсуждение исходный текст |
Ответы |
Re: Parethesis don't work correctly in where clause
|
Список | pgsql-bugs |
Your name : Casey Allen Shobe Your email address: cshobe@secureworks.com System Configuration --------------------- Architecture (example: Intel Pentium) : Intel Pentium III 1GHz Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.20 PostgreSQL version (example: PostgreSQL-6.4.2): PostgreSQL-7.3.2 Compiler used (example: gcc 2.8.0) : gcc 3.2.2 $CC environment variable : gcc -s $CFLAGS environment variable : -O3 -mcpu=i686 Please enter a FULL description of your problem: ------------------------------------------------ I have a query with: where "n"."revision" = 2 If I add: and ( "t"."name" = 'nibc' and "n"."identifier" = 12345 ) ...it works. If I add: and ( "t"."name" = 'client' and "n"."identifier" = 123 ) instead of the previous...it also works as expected. However, if I add: and ( "t"."name" = 'nibc' and "n"."identifier" = 1274 ) or ( "t"."name" = 'client' and "n"."identifier" = 383 ) PostgreSQL returns only the revision 2 tuple for nibc 1274, but also a revision 1 tuple for client 383. ONLY things matching revision 2 should be found, but for some reason the "n"."revision" = 2 isn't being applied globally, but only to the first set of parenthesis. This workaround makes it work: where ( "t"."name" = 'nibc' and "n"."identifier" = 1274 and "n"."revision" = 2 ) or ( "t"."name" = 'client' and "n"."identifier" = 383 and "n"."revision" = 2 ) ...but that can get horribly repetitive after a while. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: ---------------------------------------------------------------------- See above SQL. Apply to any table. If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- By correctly keeping the global "n"."revision" defined outside of the parenthases in a global state. -- Casey Allen Shobe, Developer & Linux Administrator SecureWorks, Inc. / 404.327.6339 x169 / Fax: 404.728.0144 cshobe@secureworks.net / http://www.secureworks.net 00001110 is good for the soul.
В списке pgsql-bugs по дате отправления: