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

Sferacarta Software <sferac@bo.nettuno.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@traverse.net                    Traverse City, Michigan, 49684
  "What good is a can of worms if you never open it?"  -Bob Arning