ULL is 10,
therefore we can't say that it isn't. Therefore, for a NOT IN (xx,yy,NULL),
all evaluations are either false or unknown).
SQL specs are clear on this point, and its covered well in Celko's
_SQL_for_Smarties_: NOT IN ( xx, yy, NULL) returns nothing.
At least
erce the value to the correct domain:
test=# select * from t2 where f='2'::typ;
f
---
(0 rows)
However, this works:
test=# select * from t2 where f='2'::char;
f
---
2
(1 row)
Is this a bug? Is this correct behavior? Am I misunderstanding this?
Thanks!
place/sed/perl/whatever the quotes out of the SQL dump
before importing to PG, or (b) once in PG, ALTER TABLE "FOO" RENAME TO
"foo".
(b) is tricky, though, as index names and ref integrity constraints and
such aren't corrected for this. (a) is a better solution.
HTH,
--
7;t have VisualC++, you can my compiled copy from
www.scw.org/pgaccess.
Good luck!
--
Joel Burton, Director of Information Systems -*- [EMAIL PROTECTED]
Support Center of Washington (www.scw.org)
to handle all cases.
> Thanks for the detailed, easy-to-reproduce bug example! These sorts
> of reports are by far the nicest from a developer's point of view ;-)
My Mom always said I loved finding problems. :-)
--
Joel Burton, Director of Information Systems -*- [EMAIL PROTECTED]
Support Center of Washington (www.scw.org)
te rule r as
on update to v do instead
( insert into c (pid, descrip) select new.pid,
new.descrip );
update v set descrip='test' where pid=2;
-- gets error "ERROR: JOIN qualification may not refer
-- to other relations"
--
Joel Burton, Director of Information Systems -*- [EMAIL PROTECTED]
Support Center of Washington (www.scw.org)
