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.        |