> > No one has told me the diffence between:
> > 
> > 	int **var 
> > 
> > and
> > 
> > 	int (*var)[]
> > 
> > but that was the fix.
> 
> If anyone does - please let me know! I thought the two were
> equivalent.

Somehow different.  It may be the difference between a pointer to a list
of int pointers, and a pointer to a pointer to a list of ints.  Does
that make sense?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle              |  (610) 353-9879(w)
  +  If your life is a hard drive,     |  (610) 853-3000(h)
  +  Christ can be your backup.        |

Mon, 21 Sep 1998 08:35:11 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills
	backend]
Hey Bruce! I've got some questions for the original topic, which was the
failure of

  select not b from t;

where b is a boolean type in table t. 

It looks to me that the NOT_EXPR expression node is being constructed
correctly in the parser, but somewhere between the parser and the
executor (at ExecSeqScan()) it is being transformed into a deficient
OP_EXPR expression node. Any hints on other places where this query tree
might be getting transformed or manipulated? If I brute force substitute
the expression type to be NOT_EXPR in ExecEvalExpr() then the query
completes successfully:

postgres=> select not b from t1;
?column?
--------
f
t
(2 rows)

Hints are appreciated, or if this is touching on areas you are already
familiar with I can send my debugging patches...

                       - Tom

Tue, 22 Sep 1998 03:55:48 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: NOT boolfield kills backend
> Hey Bruce! I've got some questions for the original topic, which was the
> failure of
> 
>   select not b from t;
> 
> where b is a boolean type in table t. 
> 
> It looks to me that the NOT_EXPR expression node is being constructed
> correctly in the parser, but somewhere between the parser and the
> executor (at ExecSeqScan()) it is being transformed into a deficient
> OP_EXPR expression node. Any hints on other places where this query tree
> might be getting transformed or manipulated? If I brute force substitute
> the expression type to be NOT_EXPR in ExecEvalExpr() then the query
> completes successfully:
> 
> postgres=> select not b from t1;
> ?column?
> --------
> f
> t
> (2 rows)
> 
> Hints are appreciated, or if this is touching on areas you are already
> familiar with I can send my debugging patches...

I would guess something in the optimizer.  Let me take a look at it.

Debugging patches, ah.  No gdb yet?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle              |  (610) 353-9879(w)
  +  If your life is a hard drive,     |  (610) 853-3000(h)
  +  Christ can be your backup.        |

Tue, 22 Sep 1998 15:20:44 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: NOT boolfield kills backend
> Hey Bruce! I've got some questions for the original topic, which was the
> failure of
> 
>   select not b from t;
> 
> where b is a boolean type in table t. 
> 
> It looks to me that the NOT_EXPR expression node is being constructed
> correctly in the parser, but somewhere between the parser and the
> executor (at ExecSeqScan()) it is being transformed into a deficient
> OP_EXPR expression node. Any hints on other places where this query tree
> might be getting transformed or manipulated? If I brute force substitute
> the expression type to be NOT_EXPR in ExecEvalExpr() then the query
> completes successfully:
> 
> postgres=> select not b from t1;
> ?column?
> --------
> f
> t
> (2 rows)
> 
> Hints are appreciated, or if this is touching on areas you are already
> familiar with I can send my debugging patches...
> 
>                        - Tom
> 

Fixed.  The last part of the 'if' statement in flatten_tlistentry() was
creating an expr that was assumed to be an OP_EXPR, while it was not in
this case.

---------------------------------------------------------------------------

	
	test=> select x from test;
	x
	-
	f
	(1 row)
	
	test=> select not x from test;
	?column?
	--------
	t       
	(1 row)

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle              |  (610) 353-9879(w)
  +  If your life is a hard drive,     |  (610) 853-3000(h)
  +  Christ can be your backup.        |

Tue, 22 Sep 1998 17:20:12 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: NOT boolfield kills backend
> Debugging patches, ah.  No gdb yet?

(I see that you fixed it. Great!)

I just cleaned up a little code; enabling some of the debugging
statements already in this area caused some breakage. Yeah, I'm now
gdb-enabled with Postgres, and it is very nice, but not if you don't
know where the code is headed. I could see the parse tree at the back of
the parser, and I could see the tree at the executor, but had no idea
where it went in between. Stepping through code didn't seem like a good
bet since afaik there are hundreds of calls in between...

                   - Tom

Wed, 23 Sep 1998 01:27:28 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: NOT boolfield kills backend
> > Debugging patches, ah.  No gdb yet?
> 
> (I see that you fixed it. Great!)
> 
> I just cleaned up a little code; enabling some of the debugging
> statements already in this area caused some breakage. Yeah, I'm now
> gdb-enabled with Postgres, and it is very nice, but not if you don't
> know where the code is headed. I could see the parse tree at the back of
> the parser, and I could see the tree at the executor, but had no idea
> where it went in between. Stepping through code didn't seem like a good
> bet since afaik there are hundreds of calls in between...
> 
>                    - Tom
> 

I suspected the optimizer, and the postmaster -d output showed the parse
and rewrite were ok, but the plan was wrong, so it had to be the
optimizer.  (New debugging levels cause -d 99 to have to be used to see
the query trees.)

I then went to the optimizer and looked for a reference to OP_EXPR,
which is the new value the expression was getting.  I saw it in
make_opclause().   I set a breakpoint on that function and executed the
query inside gdb.  It showed only one call to the function for that
query, and a backtrace on the breakpoint showed flatten_tlistentry()
making the call, and it was clear after that.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle              |  (610) 353-9879(w)
  +  If your life is a hard drive,     |  (610) 853-3000(h)
  +  Christ can be your backup.        |

Tue, 22 Sep 1998 21:43:31 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: NOT boolfield kills backend