[sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

Sferacarta Software <sferac(at)bo(dot)nettuno(dot)it> writes:
> ZV> create table t1 ( b bool );
> ZV> insert into t1 values ( 'T' );
>
> ZV> select not b from t1;
>
> Wrong syntax.

Not if he is trying to display the complement of a logical field
rather than restrict a selection. And regardless, is backend
failure an acceptable out? How about the following in 6.4beta?

create table mine (a bool);
insert into mine values (true);
select * from mine as t1,mine as t2 where t1.a or not t2.a;

Look folk. We're falling over on variations of expressions in
both our result attributes and our selection criteria, and smug-
ness won't remove bugs. A session with gdb showed that at least
in the case of:

create table t0 (a_id int4 not null, a varchar, a_t1_id int4);
insert into t0 values (1, 'at0', 0);
insert into t0 values (2, 'at0', 0);
create index a_id_t0 on t0 (a_id);
create index a_t1_id_t0 on t0 (a_t1_id);
select * from t0 where (a_id = 1 or a_id = 2) and a_t1_id < 1;

we are dereferencing NULL in the 6.4beta1 query optimizer, and I
suspect the same in my first example.

My I, a humble newcomer, make a suggestion? Should we place any
legitimate query set we've discovered to cause crashes into our
regression suite?

--
Christopher Oliver Traverse Internet
Systems Coordinator 223 Grandview Pkwy, Suite 108
oliver(at)traverse(dot)net Traverse City, Michigan, 49684
"What good is a can of worms if you never open it?" -Bob Arning