[sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] - Mailing list pgsql-hackers

From Christopher Oliver
Subject [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
Date
Msg-id 19980918140125.A397@fritz.traverse.net
Whole thread Raw
Responses Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]  ("J. Michael Roberts" <mirobert@cs.indiana.edu>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532
Next
From: David Hartwig
Date:
Subject: Serial Data Type Failure