-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Lane wrote:
> =?ISO-8859-2?Q?Miroslav_=A9ulc?= <miroslav.sulc@startnet.cz> writes:
>> Here is the complete dump and the query. In my case the bug is
>> reproducible using it.
> In a perfect world we'd not have this problem because
> const-simplification would have got rid of the IN altogether, and we'd
> have a plan equivalent to "SELECT Invoice.* FROM Invoice WHERE false".
> However making that happen seems quite difficult/risky because of
> order-of-operations issues --- we really want to do jointree
> rearrangement before we do expression simplification. Since it's
> such a hokey query (how many applications really write "WHERE false"?),
Three letters :)... O.R.M
I see this type of weirdness all the time... The most recent was
something like this:
AND ((lower(a.firstName) LIKE NULL OR NULL IS NULL)
AND (lower(a.middleName) LIKE NULL OR NULL IS NULL)
AND (lower(a.lastName) LIKE '%foo%' OR '%foo%' IS NULL)
AND (lower(b.emailAddress) LIKE NULL OR NULL IS NULL) )
Granted this isn't WHERE FALSE, but I certainly see WHERE TRUE all the
time in similar scenarios and I have seen WHERE FALSE.
Sincerely,
Joshua D. Drake
Joshua D. Drake
- --
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBSJaATb/zqfZUUQRAnPFAJ9Ut8H9MrC22xBqL4FXqNe9WpMefACdHdc8
To8QKvTQcgoicOSfAzhGYC0=
=qnfG
-----END PGP SIGNATURE-----
